Glanz und Elend von RDBMS aus Sicht der Anwendungsentwicklung

[Marinero Atlántico]

Hi,

hier will ich ein paar Sachen dazu posten. Auch die Nachteile. Die Diskussion um Objekt-Datenbanken wäre längst gestorben, gäbe es diese Ursachen nicht.

Mathias hat das in einem anderen Thread sehr guten Thread gepostet:

Und das halte ich jetzt für aufwändiger in Notes als in RDBMS "mal schnell" durch eine Table zu wandern um diese Ersetzung vorzunehmen.

Das ist schon mal ein bischen irreführend.  Es ist gerade der Vorteil von SQL und RDBMS, dass man hier über eine Menge an Tupeln (Zeilen) arbeiten kann:

Einfaches Beispiel:

Code

update Firma Set city='Chemnitz' where city='Karl Marx Stadt';

Wenn es in der Tabelle >1 Tupel (Zeile) mit dem Property (Spaltenwert) 'Karl Marx Stadt' gibt, dann werden die alle wertmässig in 'Chemnitz' geändert. Also alles andere als "rumeiern".
andere Beispiele sind group by/(having) uvam.
Das "eiern über eine Tabelle" (Relation) kommt eigentlich nur zustande, wenn man in einem Programm die Datenbankinhalte in Objekte verwandelt.
Auf SQL/RDBMS Ebene kann man über eine Menge an Daten arbeiten und das ist eine sehr gute Eigenschaft.

[Semeaphoros]

Stimmt, a-bär ich hatte Matthias nicht so verstanden, wie es den Anschein macht, dass Du es getan hast. Das Eiern (und damit das Osterfest ... ) ist bei solchen Gelegenheiten in Notes/Domino angesagt. Matthias hat mit seinem "schnell mal" eben genau das gemeint, was Du jetzt hier in konkreten Code gegossen hast, meine ich.

Zu den OO-Datenbanken: Diese Diskussion ist vieeeeel jünger als irgendwelche Diskussionen über RDBMS. OO insgesamt ist eine Generation später als RDBs, Codd ist schon bald einmal ur-alt. Daneben gilt es zu beachten, dass man auch eine ROODB andenken könnte (und das wurde auch gemacht: eine relationale OO-Datenbank, das würde sogar funktionieren). Anders ausgedrückt, mit Deiner Bemerkung über OO-DBs hast Du zu der Diskussion über Aepfel auch gleich noch die Birnen hineingeworfen, die Themen gehören nicht wirklich zusammen.

[TMC]

Danke Jens, exakt so war's gemeint.
Wollte dort nur zum Ausdruck bringen, das sowas in RDBMS viel schneller und besser geht.

[Marinero Atlántico]

Klar kann ich Leute mißverstehen.
Es geht mir nicht darum, jemanden persönlich anzugreifen, sondern um den Inhalt der Diskussion.

Codd ist schon bald einmal ur-alt.

Code

was nicht heisst, dass es schlecht ist. 

Daneben gilt es zu beachten, dass man auch eine ROODB andenken könnte (und das wurde auch gemacht: eine relationale OO-Datenbank, das würde sogar funktionieren).

Code

Klar haben z.B. Oracle oder DB2 mittlerweile auch sowas wie Objekt Features. Nur halte ich die Vereinbarkeit beider Ansätze für ein bischen fragwürdig. 
[quote author=Semeaphoros link=topic=22672.msg144203#msg144203 date=1114669557] 
Anders ausgedrückt, mit Deiner Bemerkung über OO-DBs hast Du zu der Diskussion über Aepfel auch gleich noch die Birnen hineingeworfen, die Themen gehören nicht wirklich zusammen.
[/quote]
Notes, OODBs, RDBMS erfüllen alle die selbe Business-Funktionalität: 
Die Persistierung von Daten bei Zugriff mehrerer User. 
Wieso kann man diese Ansätze nicht vergleichen ???[/quote]

[Semeaphoros]

Wurde auch nicht als Angriff aufgefasst.


Stimmt, was uralt ist, ist nicht automatisch schlecht, sonst würd ich mich bestimmt nicht mit Römern und Griechen beschäftigen ..... 

Notes, OODBs, RDBMS erfüllen alle die selbe Business-Funktionalität:
Die Persistierung von Daten bei Zugriff mehrerer User.
Wieso kann man diese Ansätze nicht vergleichen

Naja, in diese Definition gehört aber auch LanServer, Windows Server, Samba ............ selbst mit Word lässt sich das machen und man bekommt sogar noch gewisse "Kooperationsfunktionen" mitgeliefert.

Nur, Du hast angefangen mit einem Technologievergleich und nicht mit einer Betrachtung der Biz-Funktionalität. Warum änderst Du den Blickwinkel?

[Marinero Atlántico]

Jens,

ich sehe da keine Veränderung des Blickwinkels. Die Bizfunktionalität bewirkt, dass eine bestimmte Art von Datenbank in einer Anwendung eine bestimmte Aufgabe übernimmt.
Und aus Sicht der Anwendungsentwicklung kann man dass dann sehr wohl vergleichen.
Ich habe für ein bestimmtes Aufgabensegment Grüne, Rote und Gelbe Äpfel und kann auswählen.
Jede Art hat seine Vor- und Nachteile. Es soll hier nicht um einen low-level Technologievergleich gehen, zu dem ich sowieso nicht in der Lage bin.
 
Ich versuche das hier mit der mir möglichen analytischen Schärfe herauszuarbeiten.
Gerne verwendete Begriffe wie "starr" oder "unflexibel" sehe ich nicht so, bzw benötigen einiges an Erörterung. 
Es gibt aber auch definitiv Fälle, wo RDBMS einem das Leben sicher nicht einfacher machen.
Da ich z.Zt. ziemlich viel damit arbeite, versuche ich auch diese kritischen Punkte herauszuarbeiten.

Gruß Axel

[Semeaphoros]

RDBs sind definitiv überfordert, wenn Daten nicht hierarchisch daher kommen, also entweder chaotisch oder zirkulär, um die beiden wichtigsten Varianten zu nennen. Da ist eine relationale Abbildung nicht mehr adäquat.

[Marinero Atlántico]

kannst du ein Beispiel posten für zirkuläre Daten?

[Semeaphoros]

Beziehungskiste:

Wer kennt wen?

A kennt B und E, B kennt C und D, C kennt B und E, E kennt B und C .......

[Thomas Schulte]

RDBS im Klassichen Sinn sind auch dann überfordert, wenn jede beliebige Tabelle mit jeder anderen beliebigen Tabelle in einer Beziehung stehen kann (aber nicht muss).
Haus A gehört Person B
Person C wohnt in Haus A
Telefonanschluss D ist in Wohnung E
Wohnung E ist in Haus A
Person F telefoniert mit Telefonanschluß D
TelefonAnschluß D ist angemeldet von Person B

[Marinero Atlántico]

Ich liefere am Wochenenden Tabellen für PostgreSQL und DB2. 

[animate]

Beziehungskiste:

Wer kennt wen?

A kennt B und E, B kennt C und D, C kennt B und E, E kennt B und C .......

RDBS im Klassichen Sinn sind auch dann überfordert, wenn jede beliebige Tabelle mit jeder anderen beliebigen Tabelle in einer Beziehung stehen kann (aber nicht muss).
Haus A gehört Person B
Person C wohnt in Haus A
Telefonanschluss D ist in Wohnung E
Wohnung E ist in Haus A
Person F telefoniert mit Telefonanschluß D
TelefonAnschluß D ist angemeldet von Person B

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).

[Marinero Atlántico]

Jens Beispiel würde ich auch eindeutig als M-N Beziehung auf sich selber sehen.
Also auf fränkisch vielleicht :

|--------------------------------|*-------------------| relationship (u.U. als Beziehungsklasse (spelling?) an die Assoziation hängen
|        Person                     |                          | 
|                                        |*-------------------|
*------------------------------- |

Thomas Schulte versucht es mit einem DB-Warehouse Trick. Er könnte sich berufen auf "... mit jeder anderen Tabelle in Beziehung stehen kann (aber nicht muss).
Ich kenn mich nicht mit Datawarehouse aus. Aber ich glaub, da müssen die Beziehungen zwischen den Relationen schon irgendwie definiert sein. Jedenfalls stimme ich mit Thomas V. überein. Bisher waren das alles ganz normale Relationen.

[Semeaphoros]

Beziehungen auf sich selber sind in Codd (und Nachfolger) nicht erlaubt. Damit durchbricht so etwas das relationale Modell. Dass man das in UML darstellen kann, hat in dieser Hinsicht keine Bedeutung. Fakt ist, dass bei einem solchen Datenmodell Referenzintegrität und ähnliches nicht mehr mit den gängigen Mitteln sichergestellt werden kann. Es hat auch niemand - weder Thomas noch ich - gesagt, dass sich sowas nicht darstellen lassen kann, es ist einfach nicht mehr relational

[Marinero Atlántico]

In der relationalen Integrität sehe ich auch ein kleines Problem (die Beziehung kann doppelt vorhanden sein). Man braucht dafür aber nur einen kleinen Validitätscheck aus der Anwendung heraus. Oder man macht die Inserts/Updates als stored procedures und checkt das da ab.
Als wirkliche Einschränkung sehe ich das nur sehr bedingt. 

Table Person
ID Identity (autogenerated primary key)
nameP varchar(50)

Table Relation
ID Identity (autogenerated primary key)
IDPersonA BigInt --- Fremdschlüssel auf idPerson
IDPersonB BigInt --- Fremdschlüssel auf idPerson.

[Semeaphoros]

a) es spielt keine Rolle, ob das einfach zu implementieren ist oder nicht, es bricht die recht strengen Regeln der Relationalen Datenbanken (nicht unbedingt der allgemeinen Relationalität ....)

b) Ich kann Dir sagen, so ganz einfach ist es nicht, es öffnet eine ganze Reihe von "Kannen von Würmern" ...... ich hatte so ein Modell mal in einem Projekt ...

[Thomas Schulte]

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).

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.

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..

[Thomas Schulte]

Nachtrag: wenn du bei meinem Modell 100 Tabellen hast, bei denen jeder mit jeder anderen verknüpft werden kann dann bedeutet das pro Tabelle 99 Foreign Keys. 

[Marinero Atlántico]

b) Ich kann Dir sagen, so ganz einfach ist es nicht, es öffnet eine ganze Reihe von "Kannen von Würmern" ...... ich hatte so ein Modell mal in einem Projekt ...

Ich sehe ehrlichgesagt nach wie vor keine so großen Schwierigkeiten. Wenn ich mich recht erinnere basiert Gavin King/Christian Bauers Beispiel f. Hibernate in Action auf einem Modell, wo es solche Beziehungen zwischen Kategorien gibt, wenn ich mich recht erinnere. Kann mal nachschlagen.
Btw. könnte man vermutlich als Constraint einbauen, dass ID_von_PersonB_in_der_Verknüpfungstabelle > ID_von_PersonB_in_der_Verknüpfungstabelle.

@Thomas: Wo benötigt man in der Realität, dass 100 Tabellen, die alle miteinander in Beziehung stehen. Wir haben jetzt also einen hypothetischen Grenzfall, wo 100 Tabellen, die alle miteinander verbunden sind, unübersichtlich werden und vermutlich recht langsam für inserts und updates werden.

[Semeaphoros]

Axel, Du wolltest Beispiele, von Praxistauglichkeit hat niemand geredet