Richtig, und das ist auch gut so...Den deine "Idee" ist grundlegend falsch...
Das ist hier das Problem, oder?
Einfügen wenn die Daten mit sich selbst verknüpft sind?
- Ersteller jmar83
- Erstellt am
Werbung:
Hä??! Trivial sind meine Sachen ganz sicher nicht, habe aber schon komplexere Probleme gelöst. (In welcher Sprache auch immer)
Es wäre doch sogar einfacher gewesen, die Tabelle von Anfang an mit richtigen FK's zu verwenden...?
UND: Obwohl mir hier im Forum gesagt wurde, dass MySQL grundsätzlich nicht RICHTIG mit hierarchischen Daten umgehen kann (ausser mit doofen LEFT JOIN's, wo dann die Ebenen begrenzt sind, und das macht dann so ein doofes Resultset, mit Ebenen als Felder...?), kann es eben doch... gewusst wie...
Gruss, Jan
Ich will dich ja auch nicht beleidigen oderso... Aber Berg ab kann mein Auto auch einen 40t Anhänger ziehen... Ob es sinnvoll ist ist aber ne andere Sache oder?
Generier dir mal eine Tabelle mit 1 Mio. Datensätze (und einer Rekursionstiefe von einer Stufe) und warte mal bis sich deine Prozedur nach ausführen wieder meldet...
Je nach Parametrisierung kann ich dir sogar schon diverse Exceptions vorhersagen... Eine sehr wahrscheinliche dürfte hier wohl "Session timeout" sein
Ich habe nur eine Frage an dich... Inwiefern hast du deine tolle "Lösung" auf Performance getestet ?
Generier dir mal eine Tabelle mit 1 Mio. Datensätze (und einer Rekursionstiefe von einer Stufe) und warte mal bis sich deine Prozedur nach ausführen wieder meldet...
Je nach Parametrisierung kann ich dir sogar schon diverse Exceptions vorhersagen... Eine sehr wahrscheinliche dürfte hier wohl "Session timeout" sein
Ja klar...
Zur Rekursion: Aber so viele Datensätze werde ich nie haben. "Besser" wäre es sicher schon, wenn man mehr auf bspw. PHP auslagern würde so dass nur 1 Query erfolgt, der Rest mit PHP-Datenstrukturen (anstelle vom immer wieder per SELECT abfragten Resultsets) abgearbeitet werden würde. (Dann könnte man bspw. auch einen "Stack" verwenden um Rekursion zu erreichen anstelle sich immer wieder selbst aufzurufen, man müsste auch keine Methode (bei SQL "Procedure") verwenden welche kein "RETURN" kann und "by Reference"/Callback-mässig übergibt, sondern könnte eine "normale" Funktion verwenden mit "RETURN" am Ende verwenden. (Analog SQL "Function", dort ist es aber gemäss meiner Fehlermeldung so, dass keine Rekursion erfolgen darf in einer Function falls sich in der gleichen DB Trigger befinden, hmmmm na ja...)
Zu meinem Pseudo-FK für die Knoten: Da ist die Sache die, dass er nicht nur einen gültigen PK annahmen darf und NULL, sondern auch '0' (=analog NULL, muss aber '0' verwenden weil sonst das GUI stress macht. ich weiss, die DB dem GUI anzupassen ist eigentlich ziemlich blöd) und auch '-1' für den "root node"...
Und ich weiss ehrlich gesagt wirklich nicht, wie ich das über eine "normale" FOREIGN KEY Deklaration machen soll??
Gruss, Jan
Zur Rekursion: Aber so viele Datensätze werde ich nie haben. "Besser" wäre es sicher schon, wenn man mehr auf bspw. PHP auslagern würde so dass nur 1 Query erfolgt, der Rest mit PHP-Datenstrukturen (anstelle vom immer wieder per SELECT abfragten Resultsets) abgearbeitet werden würde. (Dann könnte man bspw. auch einen "Stack" verwenden um Rekursion zu erreichen anstelle sich immer wieder selbst aufzurufen, man müsste auch keine Methode (bei SQL "Procedure") verwenden welche kein "RETURN" kann und "by Reference"/Callback-mässig übergibt, sondern könnte eine "normale" Funktion verwenden mit "RETURN" am Ende verwenden. (Analog SQL "Function", dort ist es aber gemäss meiner Fehlermeldung so, dass keine Rekursion erfolgen darf in einer Function falls sich in der gleichen DB Trigger befinden, hmmmm na ja...)
Zu meinem Pseudo-FK für die Knoten: Da ist die Sache die, dass er nicht nur einen gültigen PK annahmen darf und NULL, sondern auch '0' (=analog NULL, muss aber '0' verwenden weil sonst das GUI stress macht. ich weiss, die DB dem GUI anzupassen ist eigentlich ziemlich blöd) und auch '-1' für den "root node"...
Und ich weiss ehrlich gesagt wirklich nicht, wie ich das über eine "normale" FOREIGN KEY Deklaration machen soll??
Gruss, Jan
akretschmer
Datenbank-Guru
- Beiträge
- 10.370
Nein, besser wäre, wenn die DB das kann. Dann kan Dein Client inPHP, C, Phyton, Shell-Script oder $whatever ein - es ist IMMER konsistent.
Aber MySQL hat ja kein "CTE" wie SQL Server, dann habe ich die Wahl die rekursive Procedure/Funktion selbst zu coden, entweder
a.) Auf reiner SQL-Ebene, wie ich es gemacht habe mit XML-String-Output, welcher dann bspw. per PHP-XSLT-Komponente zu HTML umgeformt wird
b.) Im Kombination mit einer höheren Programmiersprache bspw. Schleifen programmieren, in welchen direkt HTML gerendert wird
Was ist den nun "besser", von irgendwelchen Nested-Sachen mal abgesehen?
Eigentlich könnte ich meine Funktion auch noch optimieren (mit argument maxDepth oder so) damit nicht immer alle Ebenen durchgegangen werden. Von "oben" her kann man schon eingrenzen (root knoten kann auch ein Unterknoten sein!) von "unten" her noch nicht - einen Tiefencounter hat meine Funktion bereits, sollte also kein grosses Problem sein...;-)
a.) Auf reiner SQL-Ebene, wie ich es gemacht habe mit XML-String-Output, welcher dann bspw. per PHP-XSLT-Komponente zu HTML umgeformt wird
b.) Im Kombination mit einer höheren Programmiersprache bspw. Schleifen programmieren, in welchen direkt HTML gerendert wird
Was ist den nun "besser", von irgendwelchen Nested-Sachen mal abgesehen?
Eigentlich könnte ich meine Funktion auch noch optimieren (mit argument maxDepth oder so) damit nicht immer alle Ebenen durchgegangen werden. Von "oben" her kann man schon eingrenzen (root knoten kann auch ein Unterknoten sein!) von "unten" her noch nicht - einen Tiefencounter hat meine Funktion bereits, sollte also kein grosses Problem sein...;-)
Ich sage mal so... Die richtige Lösung wäre eine andere Datenbank...
Wenn man soetwas wie Rekursion in seinem Modell braucht, muss man eben schon vorher eine passende Datenbank suchen, die das Vorhaben auch umsetzen kann...
Alles andere ist einfach nur Hobby-Gebastel... Funtkioniert, hat im produktiven Code einer Firma aber nichts zu suchen
Und was ist, so wie bei mir, wenn ein bestehendes System angepasst werden muss?
Da kann mir niemand erzählen dass es Sinnvoll wäre die ganze DB auf ein anderes DBMS zu migrieren was sicher x Wochen Zeit brauchen würde nur um dieses Problem "fachgerecht" zu lösen...? ;-)
Da kann mir niemand erzählen dass es Sinnvoll wäre die ganze DB auf ein anderes DBMS zu migrieren was sicher x Wochen Zeit brauchen würde nur um dieses Problem "fachgerecht" zu lösen...? ;-)
akretschmer
Datenbank-Guru
- Beiträge
- 10.370
Eine Frickellösung wird Dir aber immer und immer wieder, spätestens nach y Wochen, um die Ohren fliegen. Der Aufwand einer Migration der DB ist sicherlich hoch, aber einmalig. Das ist also eine Abwägung, was sinnvoller für dich Dich: ein ständiges Leben mit Schmerzen, oder eine einmalige Operation.
Werbung:
Beim Chef die Schuld auf den Vorgänger schieben und Däumchen drehen...
**Ich hoffe man sieht den Sarkasmus...
Meine Vorgehensweise wäre ja wie folgt... Zumindest mal stichpunktartig zusammengefasst
Schritt 1: Beim Ersteller deines Modells (ich gehe mal davon aus es ist von einem externen Anbieter) nachfragen ob auch andere Datenbanken offiziell unterstützt werden. (Um weiterhin evtl. vorhandene Garantie und Support sicherzustellen)
Möglichkeit A: Wenn andere DBs unterstützt werden -> Eine Liste geben lassen und schonmal gedanken machen welche Funktionen von den verschiedenen DBs man evtl. gebrauchen könnte...
Möglichkeit B: Es gibt keine anderen unterstützten DBs... Bitterlich weinen und im Extremfall Harakiri begehen
Schritt 2: Beim Ersteller nachfragen ob es schon bestehende Migrationsskripte gibt / oder ob man vllt. Support bei der Migration bekommt
Schritt 3: Migrieren
Schritt 4: Deine Rekursion einbinden
Schritt 5: Den Rest deines Arbeitslauf freuen, weil du weißt das du nie wieder Probleme mit Rekursion haben wirst...
