anzahl Tabellen

Hallo,

mal eine Grundsatzfrage.

Nehmen wir einmal an, ich möchte einen Shop programmieren. Soweit nichts
besonderes. Nun möchte ich, das jeder Kunde seine Bestellungen über ein
Jahr rückwirkend noch im Shop sehen kann. Fragt mich jetzt nicht warum, das
ist nur ein Beispiel. Wenn ich jetzt davon ausgehe, das es einmal mehr als
10.000 gelistete Kunden geben wird, jder Kunden aller zwei Arbeitstage
mindestens 5 Artikel bestellt (bei Annahme von 200 Arbeitstagen im Jahr),
so sind das im Jahr insgesamt 5.000.000 Datensätze. Wenn ich nun jedem
Kunden eine eigene Tabelle für sein Archiv gebe, sind es nur noch 500 pro
Kunde, dafür aber 10.000 Tabellen.
Was ist nun weniger aufwendig für den Server?
1 Tabelle mit 5.000.000 Datensätzen oder 10.000 Tabellen mit jeweils 500
Datensätzen? Kann eine Datenbank überhaupt so viele Tabellen haben?

Leider kann ich das, ich hoffe auf Euer Verständnis, nicht testen. Kann mir
dazu jemand eine fundierte Aussage machen?

mfg

Mathias

Re: anzahl Tabellen

Mathias Fiedler schrieb:

> [...] Wenn ich jetzt davon ausgehe, das es einmal mehr als
> 10.000 gelistete Kunden geben wird, jder Kunden aller zwei Arbeitstage
> mindestens 5 Artikel bestellt (bei Annahme von 200 Arbeitstagen im Jahr),
> so sind das im Jahr insgesamt 5.000.000 Datensätze. Wenn ich nun jedem
> Kunden eine eigene Tabelle für sein Archiv gebe, sind es nur noch 500 pro
> Kunde, dafür aber 10.000 Tabellen.

Bei richtiger Indizierung der Tabelle dürfte eine große auf jeden Fall
besser sein als 10.000 kleine. Wobei ich auch noch bezweifeln möchte,
dass eine Datenbank so viele Tabellen überhaupt kann.

Gruß. Claus
--
,~°O O
O ,´ / |/|\
/ |¯`. Das neue Hochzeits-Branchenbuch im Internet ,´ / | |\
/__| `~...............................................~´ /___|/ /

Re: anzahl Tabellen

Mathias Fiedler schrieb:
> Was ist nun weniger aufwendig für den Server?
> 1 Tabelle mit 5.000.000 Datensätzen oder 10.000 Tabellen mit jeweils 500
> Datensätzen? Kann eine Datenbank überhaupt so viele Tabellen haben?

die Variante mit 5 Mio Datensätze dürfte weniger aufwendig sein und
sollte funktionieren (habe selbst schon eine Postgres mit knapp 8 Mio
Datensätzen gehabt)

10.000 Tabellen allerdings ollten IHMO nicht funktionieren

ciao Peter
--
WWW : http://www.marbaise.info/ Uptime: 58 Days 10 Hours
Projekt Stadtrecht
http://www.stadtrecht.de

Re: anzahl Tabellen

Mathias Fiedler schrieb im Newsbeitrag
> ... Wenn ich nun jedem Kunden eine eigene Tabelle für
> sein Archiv gebe, sind es nur noch 500 pro Kunde, dafür
> aber 10.000 Tabellen.
> Was ist nun weniger aufwendig für den Server?

Überleg' Dir nicht nur, wieviele Datensätze es sind, sondern auch, wie
der administrative Aufwand ist: Wenn Du pro Kunde eine Tabelle hast
und Änderungen an der Datenstruktur vornehmen willst, hast Du einen
höheren administrativen Aufwand als bei 1 Tabelle.

Eine Idee wäre auch, die Daten auf zwei Tabellen zu splitten - Tabelle
1 umfasst nur die letzten 14 Tage oder die vergangenen 4 Wochen und
Tabelle 2 die restlichen Daten der vergangenen 12 Monate. Wenn ein
Kunde nur die Bestellungen der letzten Zeit einsehen möchte, so
braucht er auch nur den Zugriff auf die kleinere Tabelle 1 ausführen.
Und bei der Einsicht in alle Daten nimmt er sicher etwas mehr Zeit für
die Recherche in Kauf. Die Erfahrung zeigt, dass für solche Zwecke die
Akzeptanz von Wartezeiten größer ist, weil es sich ja um ein "Archiv"
und keine Jetzt-Daten handelt.

> Kann eine Datenbank überhaupt so viele Tabellen haben?

Vermutlich schon, aber man muss ja immer davon ausgehen, dass ein
System lebt, d.h. weiterentwickelt wird.

Gruß, Dirk

Re: anzahl Tabellen

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: anzahl Tabellen

Andreas Kretschmer schrieb:
>> die Variante mit 5 Mio Datensätze dürfte weniger aufwendig sein und
>
> Jepp, sollten selbst für MySQL keine Herausforderung sein.

auch klar ;.)

>
>
>> sollte funktionieren (habe selbst schon eine Postgres mit knapp 8 Mio
>> Datensätzen gehabt)
>
> .oO( ich lächle da mal müde )

das hängt allerdings auch davon ab, was der OP unter Server versteht

>
>
>> 10.000 Tabellen allerdings ollten IHMO nicht funktionieren
>
> http://people.planetpostgresql.org/greg/index.php?/archives/ 37-The-million-table-challenge.html

ok da war ich wohl nicht mehr aktuell, allerdings kann ich den Sinn
nicht so ganz erkennen, 1 Mio Tabellen zu erzeugen (zudem ohne Daten)

ciao Peter
--
WWW : http://www.marbaise.info/ Uptime: 58 Days 22 Hours
Projekt Stadtrecht
http://www.stadtrecht.de

Re: anzahl Tabellen

Andreas Kretschmer wrote:
> begin Peter Marbaise wrote:
>> Mathias Fiedler schrieb:
>>> Was ist nun weniger aufwendig für den Server?
>>> 1 Tabelle mit 5.000.000 Datensätzen oder 10.000 Tabellen mit jeweils 500
>>> Datensätzen? Kann eine Datenbank überhaupt so viele Tabellen haben?
>
>> die Variante mit 5 Mio Datensätze dürfte weniger aufwendig sein und
>
> Jepp, sollten selbst für MySQL keine Herausforderung sein.
>
>
>> sollte funktionieren (habe selbst schon eine Postgres mit knapp 8 Mio
>> Datensätzen gehabt)
>
> .oO( ich lächle da mal müde )
>
>
>> 10.000 Tabellen allerdings ollten IHMO nicht funktionieren
>
> http://people.planetpostgresql.org/greg/index.php?/archives/ 37-The-million-table-challenge.html

Schön, daß du mal wieder Äpfel mit Birnen vergleichst, aber dazu
müsstest du ja auch die verschiedenen Tabellentypen (und deren
Eigenschaften) von MySQL kennen um mitreden zu können...

Stefan

Re: anzahl Tabellen

Weinzierl Stefan wrote:
> Andreas Kretschmer wrote:
>> Peter Marbaise wrote:
>>
>>> 10.000 Tabellen allerdings ollten IHMO nicht funktionieren
>>
>> http://people.planetpostgresql.org/greg/index.php?/archives/ 37-The-million-table-challenge.html
>
> Schön, daß du mal wieder Äpfel mit Birnen vergleichst, aber dazu
> müsstest du ja auch die verschiedenen Tabellentypen (und deren
> Eigenschaften) von MySQL kennen um mitreden zu können...

Ich nehme Andreas ja nun äußerst selten in Schutz, aber das ist
mal eine passende Gelegenheit. Der genannte Blog-Artikel belegt,
daß (auch) MySQL 1.000.000 Tabellen halten kann. Das ist zwar in
der Praxis weitgehend sinnlos, aber es geht.

Wie ebenfalls da angesprochen, hat ein SAP-System von 10.000
(Basis-Installation) bis über 40.000 Tabellen. Auch das läuft
problemlos. Allerdings ändert das nichts an der Tatsache, daß
das angedachte Design mit einer Tabelle pro Kunde höchst sinn-
los ist.


XL

Re: anzahl Tabellen

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: anzahl Tabellen

Mathias Fiedler!

> 1 Tabelle mit 5.000.000 Datensätzen oder 10.000 Tabellen mit jeweils 500
> Datensätzen? Kann eine Datenbank überhaupt so viele Tabellen haben?

http://bugs.mysql.com/bug.php?id=22037


Gruß
Daniel

Re: anzahl Tabellen

Dirk Ohme schrieb:
> Mathias Fiedler schrieb im Newsbeitrag
>> ... Wenn ich nun jedem Kunden eine eigene Tabelle für
>> sein Archiv gebe, sind es nur noch 500 pro Kunde, dafür
>> aber 10.000 Tabellen.
>> Was ist nun weniger aufwendig für den Server?

> Eine Idee wäre auch, die Daten auf zwei Tabellen zu splitten - Tabelle 1
> umfasst nur die letzten 14 Tage oder die vergangenen 4 Wochen und
> Tabelle 2 die restlichen Daten der vergangenen 12 Monate. Wenn ein Kunde
> nur die Bestellungen der letzten Zeit einsehen möchte, so braucht er

Ähnliche Idee: Partitionierung von Tabellen.

Chris

Re: anzahl Tabellen

Am Mon, 05 Mar 2007 12:25:01 +0100 schrieb Daniel Fischer:

> Mathias Fiedler!
>
>> 1 Tabelle mit 5.000.000 Datensätzen oder 10.000 Tabellen mit jeweils 500
>> Datensätzen? Kann eine Datenbank überhaupt so viele Tabellen haben?
>
> http://bugs.mysql.com/bug.php?id=22037
>
>
> Gruß
> Daniel

Danke Leute, für die Ausführungen.
Auch jetzt auf die Gefhr hin dass sich wieder einige auf den Schlips
getreten fühlen, es ging nicht um Sinn oder nicht Sinn, sondern um die
Machbarkeit. Für mich standen zwei Optionen zur Wahl. Entweder eine tabelle
mit 5.000.000 DS oder auch gesplittet auf 2 - 3 weitere, oder pro Kunde
eine Tabelle, was eben 10.000 Tabellen mit je 500 DS bedeutet hätte. Die
Frage war nicht, ob das Sinn macht, sondern ob es praktisch durchführbar
ist und wie sich die zwei Varianten auf die Perfromance auswirken. Was
fordert also den Rechner mehr? Viele Datensätze oder viele Tabellen. Die
Aussagen liefern immerhin schon eine Richtung. Es sind warscheinlich mehr
DS pro Tabelle einfacher zu handeln als viele Tabellen. Übrigens ist hier
keine relationale Suche nötig. Die einzelnen Tabellen pro Kunde würden nur
die Archivdaten des jeweiligen Kunden aufnehmen und auch nur von diesem
abgerufen werden. Eine Suche über mehrere dieser Tabellen ist hier nicht
nötig.

mfg

Mathias

Re: anzahl Tabellen

On 9 Mrz., 07:42, Mathias Fiedler wrote:
> [...] Übrigens ist hier keine relationale Suche nötig.
> Die einzelnen Tabellen pro Kunde würden nur die
> Archivdaten des jeweiligen Kunden aufnehmen und
> auch nur von diesem abgerufen werden. Eine Suche
> über mehrere dieser Tabellen ist hier nicht nötig.

Dann mal eine ganz andere Idee: Warum nicht die Archivdaten in XML-
Dateien (je Kunde eine) schreiben und mit XSL rendern? Es gibt ja
eigentlich nichts, was Du brauchst, was eine RDBMS rechtfertigen
würde ...

Gruß, Dirk

Re: anzahl Tabellen

On 2007-03-05, Daniel Fischer wrote:
> Mathias Fiedler!
>
>> 1 Tabelle mit 5.000.000 Datensätzen oder 10.000 Tabellen mit jeweils 500
>> Datensätzen? Kann eine Datenbank überhaupt so viele Tabellen haben?
>
> http://bugs.mysql.com/bug.php?id=22037

Und was sagt uns das? Irgendjemand findet das eine schlechte Idee,
ohne nähere Begründung.

Dabei ist das im Wesentlichen nichts anderes als Tabellenpartitionierung
"zu Fuß", was ja prinzipiell kein schlechter Ansatz ist, immerhin baut
MySQL das in der Version 5.1 direkt in den Server ein.

Also: gibt es technische Gründe, die dagegen sprechen, sehr viele Tabellen
anzulegen? Oder allgemeiner, viele Datenbanken? (z.B. eine Datenbank pro
User?)

Zum ursprünglichen Posting allerdings:
Eine Tabelle mit 5.000.000 Datensätzen sollte kein Problem sein, schon
gar nicht mit hauptsächlich lesendem Zugriff. 5.000.000 sind nicht so
viele Datensätze.

Grüße,

Florian

Re: anzahl Tabellen

Florian Laws wrote:
> On 2007-03-05, Daniel Fischer wrote:
>> Mathias Fiedler!
>>
>>> 1 Tabelle mit 5.000.000 Datensätzen oder 10.000 Tabellen mit jeweils 500
>>> Datensätzen? Kann eine Datenbank überhaupt so viele Tabellen haben?
>>
>> http://bugs.mysql.com/bug.php?id=22037
>
> Und was sagt uns das? Irgendjemand findet das eine schlechte Idee,
> ohne nähere Begründung.

Im Prinzip fragt dieser Feature-Request, ob MySQL nicht zusätzliche
Hürden schaffen könnte, damit Leute sich nicht in den Fuß schießen
können. Ich halte das ja für einen prinzipiell schlechten Ansatz.
Sollen sich Leute ruhig in den Fuß schießen. Durch Schmerzen lernt
man am gründlichsten. Und da es immer wieder Leute gibt
die auf "laß das lieber, so ein durchschossener Fuß tut weh" mit
Unglauben oder gar Beleidigtsein reagieren - nur zu!

> Dabei ist das im Wesentlichen nichts anderes als Tabellenpartitionierung
> "zu Fuß", was ja prinzipiell kein schlechter Ansatz ist, immerhin baut
> MySQL das in der Version 5.1 direkt in den Server ein.

Es ist nicht ganz das gleiche. Der wesentliche Unterschied ist die
Dimension. Bei 10 Partitionen lasse ich ja noch mit mir reden.
Aber 50.000? No way!

> Also: gibt es technische Gründe, die dagegen sprechen, sehr viele Tabellen
> anzulegen? Oder allgemeiner, viele Datenbanken? (z.B. eine Datenbank pro
> User?)

Es gibt keine harten Limits. Allerdings sind die Mechanismen hinter
den Kulissen auf sinnvolle Anzahlen ausgelegt. Die Abbildung von
Datenbanken/Tabellen auf Verzeichnisse/Files skaliert nur bedingt.
Die Permission-Tabellen haben z.B. keine Indizes, Permission-Checks
brauchen also lineare Laufzeit. Das ist kein Problem bei 100 Usern,
bei 10.000 aber vielleicht schon.

Gegenfrage: welche konkrete Anwendung für eine deutlich vierstellige
Anzahl Tabellen oder Datenbanken schwebt dir vor? Die Erfahrung lehrt
uns, daß 99% der Fragen nach der erlaubten/möglichen Anzahl Spalten
pro Tabelle, Tabellen pro Datenbank oder Datenbanken insgesamt aus
einem grundlegenden Unverständnis des relationalen Modells herrühren.
Also überrasch mich. Sei das eine andere Prozent!


XL

Re: anzahl Tabellen

Am 8 Mar 2007 22:53:36 -0800 schrieb Dirk Ohme:

> On 9 Mrz., 07:42, Mathias Fiedler wrote:
>> [...] Übrigens ist hier keine relationale Suche nötig.
>> Die einzelnen Tabellen pro Kunde würden nur die
>> Archivdaten des jeweiligen Kunden aufnehmen und
>> auch nur von diesem abgerufen werden. Eine Suche
>> über mehrere dieser Tabellen ist hier nicht nötig.
>
> Dann mal eine ganz andere Idee: Warum nicht die Archivdaten in XML-
> Dateien (je Kunde eine) schreiben und mit XSL rendern? Es gibt ja
> eigentlich nichts, was Du brauchst, was eine RDBMS rechtfertigen
> würde ...
>
> Gruß, Dirk

Weil für die ganze andere Geschichte eine DB bereits da ist. Aber die Idee
mit XML ist auch nicht schlecht. Mal sehen.

mfg

Mathias

Re: anzahl Tabellen

On 2007-03-09, Axel Schwenke wrote:
> Florian Laws wrote:
>
> Gegenfrage: welche konkrete Anwendung für eine deutlich vierstellige
> Anzahl Tabellen oder Datenbanken schwebt dir vor? Die Erfahrung lehrt
> uns, daß 99% der Fragen nach der erlaubten/möglichen Anzahl Spalten
> pro Tabelle, Tabellen pro Datenbank oder Datenbanken insgesamt aus
> einem grundlegenden Unverständnis des relationalen Modells herrühren.
> Also überrasch mich. Sei das eine andere Prozent!

Nehmen wir sowas wie einen Banner-Ad-Server:
Für jeden Bannnerabruf wird ein Eintrag in eine Abrufe-Tabelle gemacht[1],
gleichzeitig machen die Kunden, die die Anzeigen geschaltet haben,
etwas größere Abfragen um Statistiken zu erzeugen.
Die Kunden greifen stets nur auf ihre eigenen Daten zu.

Natürlich kann man die Einträge einfach mit einer Kunden-ID versehen
in eine einzige Tabelle schreiben, und immer mit der Kunden-ID selektieren.
Das wäre wäre recht geradlinig nach dem relationalen Modell.
Die Tabelle wird dann ziemlich schnell ziemlich groß.

Nimm dann noch eine ältere MySQL-Version, die nur einen Index pro Tabelle
nutzen kann, dann brauchst Du den Index für die Kunden-ID, und wenn Du
weiter nach z.B. Datum selektieren willst, hast du dafür schon keinen
Index mehr zur Verfügung.
Bei MyISAM hast man unter Umständen auch Table Lock Contention, die man
durch Partitionierung der Tabellen verringern könnte.

Das sind natürlich Workarounds, die bei aktuellen MySQL-Versionen
unter Umständen nicht mehr nötig sind, und teilweise auch kontraproduktiv.
(z.B. wegen des Table Cache.)

Man könnte sich natürlich auch überlegen, das Tabellenschema anderweitig
auf Performance zu optimieren, aber ein grundlegendes Unverständnis
des relationalen Modells seh ich da erstmal nicht.

Grüße,

Florian

[1] Wer an lock-freie INSERTs mit MyISAM denkt, denke sich halt noch
einen Sack UPDATEs dazu.
P.S.: Kann man eine MyISAM-Tabelle darauf prüfen, ob sie keine Löcher
enthält, und damit die INSERTS lock-frei ablaufen?

Re: anzahl Tabellen

Am 09.03.2007 14:09 schrieb Florian Laws:
> On 2007-03-09, Axel Schwenke wrote:
>> Florian Laws wrote:
>>
>> Gegenfrage: welche konkrete Anwendung für eine deutlich vierstellige
>> Anzahl Tabellen oder Datenbanken schwebt dir vor? Die Erfahrung lehrt
>> uns, daß 99% der Fragen nach der erlaubten/möglichen Anzahl Spalten
>> pro Tabelle, Tabellen pro Datenbank oder Datenbanken insgesamt aus
>> einem grundlegenden Unverständnis des relationalen Modells herrühren.
>> Also überrasch mich. Sei das eine andere Prozent!
>
> Nehmen wir sowas wie einen Banner-Ad-Server:
> Für jeden Bannnerabruf wird ein Eintrag in eine Abrufe-Tabelle gemacht[1],
> gleichzeitig machen die Kunden, die die Anzeigen geschaltet haben,
> etwas größere Abfragen um Statistiken zu erzeugen.
> Die Kunden greifen stets nur auf ihre eigenen Daten zu.
>
> Natürlich kann man die Einträge einfach mit einer Kunden-ID versehen
> in eine einzige Tabelle schreiben, und immer mit der Kunden-ID selektieren.
> Das wäre wäre recht geradlinig nach dem relationalen Modell.
> Die Tabelle wird dann ziemlich schnell ziemlich groß.
>

Wegen einer ID? Ohne jetzt ins Detail gehen zu wollen: Einer der
größeren Online-Newsdienste in diesem Land tut genau das, ohne dass
die Tabellen "ziemlich schnell ziemlich groß" würden. Und wenn, ist
das eigentlich auch egal - wofür *hat* man denn eine Datenbank.

Es sei Dir aber unbenommen, das bisherige Design des Rades
unangemessen zu finden und ein neues, viereckiges zu entwickeln.

> Nimm dann noch eine ältere MySQL-Version, die nur einen Index pro Tabelle
> nutzen kann, dann brauchst Du den Index für die Kunden-ID, und wenn Du
> weiter nach z.B. Datum selektieren willst, hast du dafür schon keinen
> Index mehr zur Verfügung.

Über welche Datenmengen redest Du denn (und jetzt sag bitte nicht
"viel" oder "groß" oder sowas)

>
> Das sind natürlich Workarounds, die bei aktuellen MySQL-Versionen
> unter Umständen nicht mehr nötig sind, und teilweise auch kontraproduktiv.
> (z.B. wegen des Table Cache.)
>

Dann nimm doch eine neue Version.

Re: anzahl Tabellen

On 2007-03-09, Christian Kirsch wrote:
> Am 09.03.2007 14:09 schrieb Florian Laws:
>> On 2007-03-09, Axel Schwenke wrote:
>>> Florian Laws wrote:
>>>
>>> Gegenfrage: welche konkrete Anwendung für eine deutlich vierstellige
>>> Anzahl Tabellen oder Datenbanken schwebt dir vor? Die Erfahrung lehrt
>>> uns, daß 99% der Fragen nach der erlaubten/möglichen Anzahl Spalten
>>> pro Tabelle, Tabellen pro Datenbank oder Datenbanken insgesamt aus
>>> einem grundlegenden Unverständnis des relationalen Modells herrühren.
>>> Also überrasch mich. Sei das eine andere Prozent!
>>
>> Nehmen wir sowas wie einen Banner-Ad-Server:
>> Für jeden Bannnerabruf wird ein Eintrag in eine Abrufe-Tabelle gemacht[1],
>> gleichzeitig machen die Kunden, die die Anzeigen geschaltet haben,
>> etwas größere Abfragen um Statistiken zu erzeugen.
>> Die Kunden greifen stets nur auf ihre eigenen Daten zu.
>>
>> Natürlich kann man die Einträge einfach mit einer Kunden-ID versehen
>> in eine einzige Tabelle schreiben, und immer mit der Kunden-ID selektieren.
>> Das wäre wäre recht geradlinig nach dem relationalen Modell.
>> Die Tabelle wird dann ziemlich schnell ziemlich groß.
>>
>
> Wegen einer ID?

Natürlich nicht wegen der ID, sondern wegen der Einträge, die
in der selben Tabelle landen, anstatt sich auf mehrere Tabellen
zu verteilen.

Auf Schwanzvergleiche habe ich im übrigen keine Lust.

Grüße,

Florian

Re: anzahl Tabellen

Florian Laws wrote:
> On 2007-03-09, Axel Schwenke wrote:
>> Florian Laws wrote:
>>
>> Gegenfrage: welche konkrete Anwendung für eine deutlich vierstellige
>> Anzahl Tabellen oder Datenbanken schwebt dir vor?
>
> Nehmen wir sowas wie einen Banner-Ad-Server:
> Für jeden Bannnerabruf wird ein Eintrag in eine Abrufe-Tabelle gemacht[1],
> gleichzeitig machen die Kunden, die die Anzeigen geschaltet haben,
> etwas größere Abfragen um Statistiken zu erzeugen.
> Die Kunden greifen stets nur auf ihre eigenen Daten zu.
>
> Natürlich kann man die Einträge einfach mit einer Kunden-ID versehen
> in eine einzige Tabelle schreiben, und immer mit der Kunden-ID selektieren.
> Das wäre wäre recht geradlinig nach dem relationalen Modell.
> Die Tabelle wird dann ziemlich schnell ziemlich groß.

Und da willst du jetzt mit einer Tabelle pro Kunden kontern?

Ich halte neben prinzipiellen Erwägungen [1] das Design für fehlerhaft:

1. Es gibt eigentlich keinen guten Grund, Banner-Auslieferungen in
eine Datenbank zu loggen. Traditionelle Logfiles sind deutlich
streßfreier zu handhaben. Und vor allem viel robuster.

2. Es gibt schon gar keinen Grund, Kunden aus der gleichen Tabelle
lesen zu lassen, wohinein die Webserver schreiben.

2a) schon wegen der zu erwartenden Schreib-/Lesekonflikte nicht.
2b) und weil die Kunden die Details gar nicht brauchen.


Statt dessen würde man die relevanten Daten (Banner-Auslieferungen,
Banner-Klicks) in Logfiles erfassen, diese Logfiles in regelmäßigen
Zeitabständen (täglich, stündlich oder notfalls alle 5 Minuten)
rotieren und dann eine *Auswertung* der Informationen in eine
Datenbank schreiben. Aus dieser Datenbank könnte man dann auch
vom Kunden erreichbare Statistiken generieren.


> Man könnte sich natürlich auch überlegen, das Tabellenschema anderweitig
> auf Performance zu optimieren, aber ein grundlegendes Unverständnis
> des relationalen Modells seh ich da erstmal nicht.

Du hast ja auch den wesentlichen Teil deiner "Lösung", nämlich gaaaanz
viele Tabellen zu verwenden, weggelassen.


> P.S.: Kann man eine MyISAM-Tabelle darauf prüfen, ob sie keine Löcher
> enthält, und damit die INSERTS lock-frei ablaufen?

SHOW TABLE STATUS zeigt für MyISAM Tabellen in `Data_free` wieviel
Platz in "Löchern" im Datenfile ist.


[1] Banner - bzw. ganz allgemein Werbung - sind die Pest des Webs.
Ohne "Adblock Plus" und "Remove it permanently" wären weite Teile
des Webs (incl. Heise.de) unerträglich.
Ich wünsche all den Firmen, die diesen Mist ins Netz pumpen, daß
ihre Datenbanken explodieren mögen! Stündlich!

XL

Re: anzahl Tabellen

On 9 Mrz., 07:53, "Dirk Ohme" wrote:
> On 9 Mrz., 07:42, Mathias Fiedler wrote:
>
> Dann mal eine ganz andere Idee: Warum nicht die Archivdaten in XML-
> Dateien (je Kunde eine) schreiben und mit XSL rendern? Es gibt ja
> eigentlich nichts, was Du brauchst, was eine RDBMS rechtfertigen
> würde ...

Weil XSL nicht auf "grosse" Anzahlen von Datensätzen skaliert. Es wirt
immer ein DOM-Baum für das komplette Dokument benötigt.

Es gibt übrigens auch nichts, was XSL rechtfertigen würde.

Gruß,
Joachim