Datensatzanzahl zwischenspeichern? Performance...

[minicrispie]

Hallo,

ich hab ein Problem mit einem DB-Entwurf( MySQL-Client-Version: 5.1.41 ).
Wobei es eigentlich kein Problem ist, sondern eine Performancefrage. Also:
Ich hab 3 Tabellen. Diese Bilden eine Hierarchie:

+------+       +------+       +------+
|  C   |       |  B   |       |  A   |
+------+  n:1  +------+  n:1  +------+
| id   |   +---| id   |   +---| id   |
| id_B |---+   | id_A |---+   +------+
+------+       +------+

Nun hab ich das Problem, dass ich sehr oft die Anzahl abfrage. Also:

• Wie viel B's besitzt A?
• Wie viel C's besitzt B?
• Wie viel C's besitzt A?

Da diese Abfragen sehr oft gemacht werden, ist es natürlich performancelastig, zudem auch INNER JOINS über 2 und 3 Tabellen.
Ist es da besser, in Tabelle A ein Feld zu machen und darin die Anzahl der B's und C's unter A zu speichern?
Natürlich müsste ich die Anzahl bei jedem Erstell- und Löschvorgang entsprechend hoch- oder runterzählen.

Das erstellen von A's, B's oder C's, kommt eigentlich wesentlich weniger vor als das Anzeigen.

Mach ich mir jetzt Performance-Sorgen wegen nichts? Sollte ich es beim Alten belassen oder Felder mit der Anzahl reinspeichern?

MfG. Christoph Ludwig

[Tom]

Hello,

Ist es da besser, in Tabelle A ein Feld zu machen und darin die Anzahl der B's und C's unter A zu speichern?
Natürlich müsste ich die Anzahl bei jedem Erstell- und Löschvorgang entsprechend hoch- oder runterzählen.

Das erstellen von A's, B's oder C's, kommt eigentlich wesentlich weniger vor als das Anzeigen.

Wenn die Anzahl keine Auswirkung auf die Integrität der Daten hat, dann kann es tatsächlich sinnvoll sein, sie zusätzlich mitzuführen im sogenannten "Kopfdatensatz". MySQL macht intern z.B. mit der Autoincrement-ID nicht anderes.

Das köntne dann am besten durch Verwendung von Stored Procedures und Triggers erledigen, die die Datenhaltungsschicht gegen die Datenveränderungsschicht abgrenzen.

Das bedeutet also, dass Du keinem Prozess mehr direkten Zugang auf eine Tabelle gewährst, sondern diesen Zugang nur per Stored Routine zur Verfügung stellst. Was die dann als Verwaltungsaufgabe zusätzlich erledigen muss, wäre z.B. das Hochzählen des Zählers in der Kopftabelle.

Für das Löschen und Ändern benötigst Du dann allerdings entsprechende Routinen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

ich hab ein Problem mit einem DB-Entwurf( MySQL-Client-Version: 5.1.41 ).

Die Server-Version wäre eine wichtigere Information als die der Client-API. Oft haben beide die gleiche Version (Client und Server aus den selben Quellen erstellt) aber eben nicht immer (Client und Server laufen getrennt und in unterschiedlichen Versionen).

Ist es da besser, in Tabelle A ein Feld zu machen und darin die Anzahl der B's und C's unter A zu speichern?
Natürlich müsste ich die Anzahl bei jedem Erstell- und Löschvorgang entsprechend hoch- oder runterzählen.

Das ist Aufwand, den man einem Trigger übereigenen könnte.

Mach ich mir jetzt Performance-Sorgen wegen nichts?

Hast du denn aktuell Performance-Probleme? Was sagt EXPLAIN? Sind Indexe vorhanden und werden diese genutzt?

Lo!

[Struppi]

ich hab ein Problem mit einem DB-Entwurf( MySQL-Client-Version: 5.1.41 ).
Wobei es eigentlich kein Problem ist, sondern eine Performancefrage. Also:
Ich hab 3 Tabellen. Diese Bilden eine Hierarchie:

+------+       +------+       +------+
|  C   |       |  B   |       |  A   |
+------+  n:1  +------+  n:1  +------+
| id   |   +---| id   |   +---| id   |
| id_B |---+   | id_A |---+   +------+
+------+       +------+

Nun hab ich das Problem, dass ich sehr oft die Anzahl abfrage. Also:

• Wie viel B's besitzt A?
• Wie viel C's besitzt B?
• Wie viel C's besitzt A?

Das klingt für mich eigentlich nicht sonderlich schwierig oder performancelastig.

Mach ich mir jetzt Performance-Sorgen wegen nichts? Sollte ich es beim Alten belassen oder Felder mit der Anzahl reinspeichern?

Vermutlich nein, wichtiger sind die richtigen Indizies. Diese Frage kannst du mit Hilfe des schon erwähnten Explain klären

Struppi.