MySQL data type

[dedlfix]

Tach!

Versuch die Regel erstmal in normalsprachlichen Worten zu verfassen. Was soll passieren, was darf nicht passieren, gibt es Ausnahmen?

Szenario 1 ( noch von Heute morgen ):

Drei Tabellen, alle Daten der Haupttabelle sollen in der Ausgabe auftreten, zu jedem Datensatz der Haupttabelle, gibt es 0-12 Einträge der 2ten Tabelle und zu jedem Eintrag der 2ten gibt es 0-xy Einträge in Tabelle 3. Haupttabelle und 2te sind über $sid verknüpft, 2te und 3te über $pid.

Ich wollte dein Augenmerk mehr auf die Verknüpfungsbedingungen lenken, nicht so sehr auf die allgemeine Beschreibung der Aufgabenstellung. Aber gut, die liest sich eher einfach, so nach dem Motto eins-drei-viele, wie bei einem Baum seinen Ästen und deren Blätter. Da entsteht eigentlich nicht mehr als notwendig, wenn man so einen Baum flachklopft, also die Blätter und dazu stets der Stamm und der eine Ast zwischen den beiden.

Szenario 2:

5 Tabellen, Hauptabelle hat 0-xy Einträge pro Nutzer, Tabellen 2 und 3 haben pro Haupttabellen Eintrag einen Eintrag, Tabellen 4 und 5 haben pro Hauptabellen Eintrag 21 Einträge. (Was 441 Iterationen ergibt, weshalb ich erst darauf gekommen bin). Alle Tabellen über $pid verknüpft.

Es scheint, es gibt keine Beziehung zwischen Tabelle 4 und 5. Dann ist es vermutlich auch nicht sinnvoll die Datenmenge zu vereinigen und sich mit einem kartesischen Produkt rumzuschlagen, das man gar nicht haben möchte.

Man muss ja nicht unbedingt für jeden Datensatz der Haupttabelle eine eigene Abfrage starten. Es gibt da ja auch Operatoren wie IN(), in dem man die IDs der Haupttabelle auflistet, die man in deren Ergebnismenge findet. Oder man gibt die Bedingung der Hauptquery auch bei den Folgequerys an und hat dann auch genau die zur Hauptquery passenden Datensätze. Die Verknüpfung muss man dann nach oder während des Fetchens der Ergebnismenge selbst herstellen. Das ist aber nicht unbedingt mehr Aufwand, als man durch einen Gruppenwechsel-Mechanismus im anderen Fall hätte. Das ist womöglich sogar performanter als wenn das DBMS sich mit einem Join abmühen muss und dabei jede Menge redundante Daten der mehr oder weniger kartesich vervielfachten Hauptquery-Datensätze entstehen.

Es gibt übrigens auch noch Alternativen zu Joins, jedenfalls in einigen Fällen. Wenn man von der einen Tabelle nur einen einzelnen Feldinhalt pro Datensatz der anderen Tabelle haben möchte, dann kann man da mit Correlated Subquerys arbeiten. Das erspart einem die Kopfschmerzen, die so ein Join bereitet, und man kann beide Teilquerys sehr schön separat testen. Wenn allerdings mehr als ein Feld benötigt wird, müsste man eine weitere korrelierte Unterabfrage für dieses erstellen, und dann fängt es an, sich nicht mehr gegenüber einem Join zu lohnen.

dedlfix.