gehen 'recursive' joins
Problem
habe zwei Tabellen (also eigentlich sind es wesentlich mehr, aber entscheident sind die beiden)
Diese sollen eine Art Dateisyystem nachbilden.
in Tabelle1 stehen alle Verzeichnisse und Dateien mit ID, vollem Namen und einige (unwesentliche) Attribute.
Tabelle2 ist nur eine Relationstabelle mit parentID und childID
beide ID's stammen aus Tabelle1 und geben an, welche Dateien/Verz(childID) zu einem Verzeichniss(parentID) aus Tabelle1 gehören.
bsp:
tabelle1:
-------------
ID | name
1 | /dir1
2 | /dir1/dir1_2/datei1.xxy
3 | /dir1/dir1_2
4 | /dir1/dir1_2/datei2.xxy
5 | /dir1/datei3.xxy
tabelle2:
---------------
parentID | childID
1 | 3
3 | 2
3 | 4
1 | 5
Wie müßte die Abfrage lauten, um alle Datei- und Verzeichnisnamen aus dir1 auszulesen?
Habe ich hier einen Designfehler ?
habe zwei Tabellen (also eigentlich sind es wesentlich mehr, aber entscheident sind die beiden)
Diese sollen eine Art Dateisyystem nachbilden.
in Tabelle1 stehen alle Verzeichnisse und Dateien mit ID, vollem Namen und einige (unwesentliche) Attribute.
Tabelle2 ist nur eine Relationstabelle mit parentID und childID
beide ID's stammen aus Tabelle1 und geben an, welche Dateien/Verz(childID) zu einem Verzeichniss(parentID) aus Tabelle1 gehören.
bsp:
tabelle1:
-------------
ID | name
1 | /dir1
2 | /dir1/dir1_2/datei1.xxy
3 | /dir1/dir1_2
4 | /dir1/dir1_2/datei2.xxy
5 | /dir1/datei3.xxy
tabelle2:
---------------
parentID | childID
1 | 3
3 | 2
3 | 4
1 | 5
Wie müßte die Abfrage lauten, um alle Datei- und Verzeichnisnamen aus dir1 auszulesen?
Habe ich hier einen Designfehler ?
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »ospx« (22. Januar 2008, 13:05)
Hi,
ich denke z.b. so für parentID 1
Gruß
.:lay-z-cow:.
ich denke z.b. so für parentID 1
|
|
Quellcode |
1 |
SELECT tabelle1.name FROM tabelle1, tabelle2 WHERE tabelle1.ID = tabelle2.childID AND tabelle2.parentID = 1 |
Gruß
.:lay-z-cow:.
Guten Tag, Tag zusammen - Ich stecke eure kleine Welt in Flammen...
Burning-Star - Back in Town!
Burning-Star - Back in Town!
RE: gehen 'recursive' joins
Warum ist nicht einfach in Tabelle noch ein Feld "parentID"? Warum diese zweite Tabelle?
Zitat
Original von ospx
tabelle1:
-------------
ID | name
1 | /dir1
2 | /dir1/dir1_2/datei1.xxy
3 | /dir1/dir1_2
4 | /dir1/dir1_2/datei2.xxy
5 | /dir1/datei3.xxy
tabelle2:
---------------
parentID | childID
1 | 3
3 | 2
3 | 4
1 | 5
Das geht so einfach nicht. Dafür müsstest Du zu jedem Child auch jeden Parent abspeichern, dann würde es gehen.
Zitat
Wie müßte die Abfrage lauten, um alle Datei- und Verzeichnisnamen aus dir1 auszulesen?
Also müsste in Tabelle zwei auch folgender Eintrag sein z.B.
parentID | childID
1 | 2
1 | 4
Dann könnte es gehen.
Marty
@MartyMcFly
danke für deine Bestätigung, dass das so nicht geht.
Bin bei komplexeren joins oder where clauses immer sehr unsicher, ob etwas gar nicht geht, oder ich einfach nur etwas falsch mache.
Hatte ich mir mitlerweile auch gedacht. Die zweite Tabelle ist schon herausgenommen und parentID in tabelle1, 2. Tabelle war Quark.
hmm - eigentlich logisch. Das ist jedoch sehr ungut, da damit die Anzahl der der Schreibzugriffe bzw Queries enorm ansteigen würden und der clientseitige Code unverhältnismäßig aufgebläht würde.
Stringfunktionen in Queries zu verwenden ist zwar auch nicht das gelbe, konnte mein Probl damit aber recht einfach lösen und die Geschwinidigkeit dieser Abfragen ist höher, als vorher von mir erwartet.
danke für deine Bestätigung, dass das so nicht geht.
Bin bei komplexeren joins oder where clauses immer sehr unsicher, ob etwas gar nicht geht, oder ich einfach nur etwas falsch mache.
Zitat
Warum ist nicht einfach in Tabelle noch ein Feld "parentID"? Warum diese zweite Tabelle?
Hatte ich mir mitlerweile auch gedacht. Die zweite Tabelle ist schon herausgenommen und parentID in tabelle1, 2. Tabelle war Quark.
Zitat
Dafür müsstest Du zu jedem Child auch jeden Parent abspeichern
hmm - eigentlich logisch. Das ist jedoch sehr ungut, da damit die Anzahl der der Schreibzugriffe bzw Queries enorm ansteigen würden und der clientseitige Code unverhältnismäßig aufgebläht würde.
Stringfunktionen in Queries zu verwenden ist zwar auch nicht das gelbe, konnte mein Probl damit aber recht einfach lösen und die Geschwinidigkeit dieser Abfragen ist höher, als vorher von mir erwartet.
warum sollte der clientseitige code aufgebläht werden, wenn du etwas mit php/mysql abfragst???
wenn du jedem child einen parent zuweist und es dann nach noch nach parent sortierst ist das sicherlich um einiges performanter.
gruß
.:lay-z-cow:.
wenn du jedem child einen parent zuweist und es dann nach noch nach parent sortierst ist das sicherlich um einiges performanter.
gruß
.:lay-z-cow:.
Guten Tag, Tag zusammen - Ich stecke eure kleine Welt in Flammen...
Burning-Star - Back in Town!
Burning-Star - Back in Town!
@lay-z-cow
mit client meine ich in diesem Fall php oder java als client von mysql.
Die entsprechenden child- und parentID's müßten ja ebenso durch php -oder java-Anwendung richtig gesetzt werden (durch INSERT's).
Die Zuordnungstabelle würde sehr schnell anwachsen, wenn jedem parent die child_childID's, child_child_childID's, ....etc zugeordnet würden und die entsprechend richtige Zuordnung für INSERT's neuer Datensätze wäre in meinem Fall auch nicht ganz trivial - und würde wesentlich komplexeren php-code und eventuell mehr sql-Abfragen erforderlich machen.
Das steht in meinem konkreten Fall nicht im Verhältniss zu dem Nutzen, den ich durch diese Zuordnung erzielen würde.
Derzeit filtere ich die richtigen Zuordnungen der Dateien und Verzeichnisse nun durch die Mysql-String-Funktionen, da ja jeder Dateiname aus dem vollständigen Pfad besteht:
ist natülich nicht optimal aber im betreffenden Fall annehmbar.
Ich kann damit alle Unterverzeichnisse und alle Dateien( auch in Unterverzeichnissen beliebiger Tiefe) in einem statement auslesen/bearbeiten/löschen. Und das war ja, was ich wollte.
mit client meine ich in diesem Fall php oder java als client von mysql.
Die entsprechenden child- und parentID's müßten ja ebenso durch php -oder java-Anwendung richtig gesetzt werden (durch INSERT's).
Die Zuordnungstabelle würde sehr schnell anwachsen, wenn jedem parent die child_childID's, child_child_childID's, ....etc zugeordnet würden und die entsprechend richtige Zuordnung für INSERT's neuer Datensätze wäre in meinem Fall auch nicht ganz trivial - und würde wesentlich komplexeren php-code und eventuell mehr sql-Abfragen erforderlich machen.
Das steht in meinem konkreten Fall nicht im Verhältniss zu dem Nutzen, den ich durch diese Zuordnung erzielen würde.
Derzeit filtere ich die richtigen Zuordnungen der Dateien und Verzeichnisse nun durch die Mysql-String-Funktionen, da ja jeder Dateiname aus dem vollständigen Pfad besteht:
|
|
Quellcode |
1 2 3 4 5 |
sql:
...
WHERE LEFT({$this->table}.`name`,CHAR_LENGTH('{$this->name}'))='{$this->name}'
...
|
ist natülich nicht optimal aber im betreffenden Fall annehmbar.
Ich kann damit alle Unterverzeichnisse und alle Dateien( auch in Unterverzeichnissen beliebiger Tiefe) in einem statement auslesen/bearbeiten/löschen. Und das war ja, was ich wollte.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »ospx« (24. Januar 2008, 15:20)


