Nested Sets mit Leeren Ästen und Blättern

[jetwork]

Hallo Zusammen,


Wie ihr von meiner früheren Fragen weiß, versuchen wir in unserer Firma eine geeignete Lösung für unsere hierarchische Datenbank finden.
Jetzt haben wir neue Ideen für unseren Fall. In unsere Firma benutzen wir MySQL deswegen wollen wir Nested Sets benutzten. Ihr habt in diesem Forum auch so empfohlen weil Nested Sets keine Rekursive Abfragen braucht.
Aber ein Nachteil von Nested Sets ist dass die Einfüge- und Entferne Anomalien sehr aufwendig sind und während Einfügen und Entfernen muss das Baum für alle Benutzer gesperrt und jedes Mal neustrukturiert werden. Unsere Datenbankbenutzer müssen aber in unseren Baum sehr oft neue Asten und Blätter hinzufügen, deswegen sind Nested Sets auch nicht sehr gut geeigtnet.
Wir (Database Admins) haben die Idee gehabt in unseren Nested Set Baum einige Leere Asten und Blätter hinzuzufügen und falls nötig werden diese Asten und Blätter durch die Datenbankbenutzer gefüllt werden.

Dadurch muss man nicht das Baum jedesmal neu strukturieren und die Strukture und links und rechts ids werden nicht verwirrend für die Benutzer sein.

Ist das eine schlechte Idee?


Danke im Voraus

 

[akretschmer]

Jetzt haben wir neue Ideen für unseren Fall. In unsere Firma benutzen wir MySQL deswegen wollen wir Nested Sets benutzten. Ihr habt in diesem Forum auch so empfohlen weil Nested Sets keine Rekursive Abfragen braucht.
Aber ein Nachteil von Nested Sets ist dass die Einfüge- und Entferne Anomalien sehr aufwendig sind und während Einfügen und Entfernen muss das Baum für alle Benutzer gesperrt und jedes Mal neustrukturiert werden. Unsere Datenbankbenutzer müssen aber in unseren Baum sehr oft neue Asten und Blätter hinzufügen, deswegen sind Nested Sets auch nicht sehr gut geeigtnet.

In kurz: ihr wißt, daß ihr die falsche Lösung nutzt.

Wir (Database Admins) haben die Idee gehabt in unseren Nested Set Baum einige Leere Asten und Blätter hinzuzufügen und falls nötig werden diese Asten und Blätter durch die Datenbankbenutzer gefüllt werden.
Ist das eine schlechte Idee?

Ich denke ja. Es löst ja das Problem nicht.

 

[Hony%]

Ist das eine schlechte Idee?

Das wirft das komplette Konzept hinter Nested Sets über den Haufen.

Unsere Datenbankbenutzer müssen aber in unseren Baum sehr oft neue Asten und Blätter hinzufügen

Dann sind Nested Sets von Haus aus eher ungeeignet. In diesem Fall ist es sinnvoll, wenn auch ineffizient, die Rekursion in der abfragenden Anwendung zu implementieren.

Dadurch muss man nicht das Baum jedesmal neu strukturieren und die Strukture und links und rechts ids werden nicht verwirrend für die Benutzer sein.

Die IDs dienen der Verwaltung und sollten dem Benutzer nicht angezeigt werden.

In unsere Firma benutzen wir MySQL

Mittelfristig dürfte es euch günstiger kommen auf ein anderes DBMS zu migrieren.

 

[jetwork]

In kurz: ihr wißt, daß ihr die falsche Lösung nutzt.

Was ist eine Fasche Lösung? Nested Sets oder MySQL?
Wenn du MySQL meinst. Ich will leider keinen Umstieg in ein anderes Datenbanksystem machen? Ein anderes Datenbanksystem wird auch irgendwo auch seine Schwachstellen haben.

 

[akretschmer]

Ich will leider keinen Umstieg in ein anderes Datenbanksystem machen?

Parse error.

 

[Hony%]

Ein anderes Datenbanksystem wird auch irgendwo auch seine Schwachstellen haben.

Dir ist schon klar, dass sich damit sogar eine Excel-Tabelle als Datenbank begründen lässt?

 

[jetwork]

Die IDs dienen der Verwaltung und sollten dem Benutzer nicht angezeigt werden.

Vielen Dank. Du meinst die Benutzer dürfen die IDs nicht sehen. Das heißt für alle Einfüge- und Löschanomalien soll ich MySQL Prozeduren hinzufügen?

Die Anwender werden nur meine Prozeduren benutzen, werden Sie dadurch nicht verwirrend mit der Änderung dieser Rechts und Links IDs oder?

 

[Hony%]

Die Anwender werden nur meine Prozeduren benutzen

Die Verwaltung des Baums sollte vollständig im Hintergrund arbeiten. Der Benutzer selbst wird für gewöhnlich sowieso nicht wissen welche Zahlen er eingeben muss. Wenn der Baum mehr als 2-3 Äste mit je 2-3 Blättern hat ist normalerweise sowieso Schluss mit manuellen Änderungen. Das ist einfach nicht beherrschbar.

 

[jetwork]

Ihr spricht zu philosophisch für mich
Ich kann euch leider nicht so gut verstehen

Parse error.

@akretschmer Parse Error heißt dass ich es falsch verstanden habe. Du hast nicht MySQL sondern Nested sets als eine falsche Lösung bezeichnet oder ?

Dir ist schon klar, dass sich damit sogar eine Excel-Tabelle als Datenbank begründen lässt?

[USER=1580]
@Hony% Und Das heißt das MySQL an manche stellen so schwach wie Excel ist oder was?[/user]

 

[Hony%]

Und Das heißt das MySQL an manche stellen so schwach wie Excel ist oder was?

Nein. Ich will dir das verdeutlichen.

Meine persönliche Lieblingsdatenbank ist SQLite. SQLite ist ein sehr kompaktes System für lokale Datenbanken und beschränkt sich daher auf einen überschaubaren Funktionsumfang. Für viele Anwendungsfälle ist dieser Funktionsumfang aber völlig ausreichend. Jetzt gibt es aber auch Situationen in denen ich zum Beispiel eine Benutzerverwaltung oder gespeicherte Prozeduren benötige. Dann ist SQLite einfach nicht mehr geeignet weil das nicht zum Funktionsumfang gehört.

In so einer Situation habe ich zwei Möglichkeiten. Entweder einen oder mehrere Workarounds bauen oder ein geeignetes DBMS wie zum Beispiel PostgreSQL benutzen. Oder, wenn es eine lokale Datenbank (unter Windows) bleiben soll ginge auch MS-SQL Compact.

Wer nur einen Hammer hat, für den ist alles ein Nagel.

 

[akretschmer]

Ihr spricht zu philosophisch für mich
Ich kann euch leider nicht so gut verstehen


@akretschmer Parse Error heißt dass ich es falsch verstanden habe. Du hast nicht MySQL sondern Nested sets als eine falsche Lösung bezeichnet oder ?

Nein, auf "Ich will leider keinen Umstieg in ein anderes Datenbanksystem machen?". Und wenn MySQL die Frage ist, dann ist (meine) Antwort Nein.

 

[ukulele]

ginge auch MS-SQL Compact.

Du meinst vermutlich MS SQL Express.

Was ist eine Fasche Lösung? Nested Sets oder MySQL?
Wenn du MySQL meinst. Ich will leider keinen Umstieg in ein anderes Datenbanksystem machen? Ein anderes Datenbanksystem wird auch irgendwo auch seine Schwachstellen haben.

Ich sage es bieten sich an:
Postgre SQL
MS SQL bzw. MS SQL Express
Oracle

Alle diese Datenbanken sind weit verbreitet und haben eigentlich keine Schwachstelle, die euch betreffen würde. Eine große Anwenderbasis sorgt für viele Lösungsvorschläge und Know-How. Alle bieten, im Gegensatz zu MySQL rekurisve Abfragen. PG ist die einzige Datenbank die hier völlig frei ohne Lizenzkosten eingesetzt werden kann.

SQLite scheint mir ungeignet weil es den lokalen Fokus hat. Es mag andere geignete DBs geben die auch speziellere Eigenschaften haben und irgendwas toller können. Auf diese mag deine Aussage zutreffen.

 

[Hony%]

Du meinst vermutlich MS SQL Express.

Nein, ich meine schon Compact.

Die Version ist im Vergleich zu Express und natürlich der Pro-Variante eingeschränkt. Allerdings auch nur ein paar Megabyte groß. Compact ist ähnlich SQLite eine lokale Datenbank und legt sein Augenmerk auf hohe Integration für .NET-Programme.

SQLite scheint mir ungeignet weil es den lokalen Fokus hat.

SQLite ist hier völlig ungeeignet. Schon alleine weil es keine Benutzerverwaltung gibt. Das ändert aber nichts daran, dass es sich dabei um meine persönliche Lieblingsdatenbank handelt die ich wenn erforderlich durch eine geeignetere ersetze.

 

[ukulele]

Ah okay kenne ich noch nicht.