Sonstiges > Infrastruktur

Glanz und Elend von RDBMS aus Sicht der Anwendungsentwicklung

<< < (6/7) > >>

Thomas Schulte:

--- Zitat von: Marinero Atlántico am 28.04.05 - 17:07:18 ---@Thomas: Das ist aber auch kein RDBMS spezifisches Problem.
Wenn du in einer Notes-Datenbank 100 DBLookups auf 100 unterschiedliche Views macht, würden vermutlich nach Tabelle 54 auch nur die ganz hartgesottenen weitermachen, denen Responsivität völlig egal ist.
Das gleiche gilt imho für OODBMS. Dort in einem Objekt 100 Pointer auf Objekte in anderen Objektbäumen ist vermutlich auch nicht so das Gelbe.

--- Ende Zitat ---
:D Hat ja auch keiner behauptet.  ;D
Was ich allerdings behaupte ist, das es für dieses Problem eine Lösung gibt, die genau diese Anforderungen abdeckt, die performant und stabil ist und die man sowohl mit nicht strukturierten Systemen (Notes) , mit RBDs und mit OODBMS hinkriegt. Wobei man und da wären wir wieder beim Thema RDBs schon etwas verbiegen müsste, so das es den strengen Anforderungen nicht mehr entsprechen würde.

Thomas Schulte:
Ach ja Jens, das geht dann auch ohne Caching

Semeaphoros:
Ja, das glaub ich Dir auch (hatte schliesslich mit ähnlichen Strukturen schon zu tun :) ) - Aber wie schon erwähnt, wir kommen vom Thema ab.

animate:

--- Zitat von: Thomas Schulte am 28.04.05 - 16:20:19 ---
--- Zitat von: Thomas Völk am 28.04.05 - 15:03:43 ---Hmm? Das sind doch stinknormale Relationen, oder nicht?

Sowas kann ich auf jeden Fall in UML-Klassendiagramm darstellen und ich denke auch, dass ich das auf eine relationale Datenbank übertragen kann (Bin da nicht so der ultra Spezialist, aber ich weiß, dass wir hier aus Klassendiagrammen die Tabellen generieren lassen und das ist sowas an der Tagesordnung).

--- Ende Zitat ---
Das ist jede für sich tatsächlich eine Stinknormale Relation.
ABER alles zusammen nicht mehr vernünftig mit den Relationalen Modell darstellbar. da du ja in jeder Tabelle für jede Beziehung zu jeder anderen Tabelle einen neuen Foreign Key eintragen müsstest. Und zusätzlich müsste jeder dieser Keys Mehrfachwerte annehmen was eigentlich auch nicht erlaubt ist.

--- Ende Zitat ---

ich hab keine Ahnung, ob ich damit eine Regel breche, aber ich muss doch weder x ForeignKeys noch Mehrfachwerte in einer Spalte haben. Das kann ich doch alles über Beziehungs-Tabellen machen, in denen jeweils die ID der zueinander in Beziehung stehenden Datensätze steht.


--- Zitat ---Und es geht nicht darum ob man das mit UML darstellen kann, oder ob es mit einer kleinen Beugung des Relationalen Modells nicht doch geht sondern wie Jens schon gesagt hat darum ob das die Regeln bricht. Und das machen beide Definitionen,  die von Jens und meine auch..

--- Ende Zitat ---

Das mit der UML habe ich deshalb aufgeführt, weil mich ER-Diagramme immer an Klassenmodelle erinnern. Und ein ER-Diagramm biette mir ebenfalls die Möglichkeit, die oben genannten Beispiele zu modellieren.


--- Zitat --- Beziehungen auf sich selber sind in Codd (und Nachfolger) nicht erlaubt
--- Ende Zitat ---

Codd kenne ich nur als "irgendein Datenbankguru aus den 60ern"
Heißt das, eine Tabelle darf keine Beziehung mit sich selbst haben?
Auch nicht über eine "reine Beziehungstabelle"?

Semeaphoros:

--- Zitat von: Thomas Völk am 28.04.05 - 17:38:59 ---Codd kenne ich nur als "irgendein Datenbankguru aus den 60ern"
Heißt das, eine Tabelle darf keine Beziehung mit sich selbst haben?
Auch nicht über eine "reine Beziehungstabelle"?

--- Ende Zitat ---

Aendere mal die Zeit um ca. 10 Jahre nach hinten :), auch wenn er in den 60ern damit angefangen hat. Und ja, Relfexivität ist in reinen relationalen DBs nicht erlaubt. Man kann es auch anders herum sagen: Relationale DBs sind zwingend hierarchisch aufgebaut (man beachte dabei, dass eine Tabelle nur ein Bestandteil einer DB ist).

Natürlich gibt es für diese Restriktion irgendwelche Gründe, aber frag mic nicht danach, ich weiss es nicht mehr.

Hab auch keine Ahnung mehr, wie das in einer Netzwerk-DB aussehen würde, kann sein, dass es sich dort direkt abbilden lässt. Aber diese Tierchen kennt ja wohl eh niemand mehr.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete