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:
update Firma Set city='Chemnitz' where city='Karl Marx Stadt';
Codd ist schon bald einmal ur-alt.CodeDaneben 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).was nicht heisst, dass es schlecht ist.CodeKlar 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]
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 ???
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?Das ist jede für sich tatsächlich eine Stinknormale Relation.
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).
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.
Axel, Du wolltest Beispiele, von Praxistauglichkeit hat niemand geredetAuch wenn du recht hast Jens aber jetzt spaltest du Haare ;D
Auch wenn du recht hast Jens aber jetzt spaltest du Haare ;D
@Thomas: Das ist aber auch kein RDBMS spezifisches Problem.:D Hat ja auch keiner behauptet. ;D
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.
Hmm? Das sind doch stinknormale Relationen, oder nicht?Das ist jede für sich tatsächlich eine Stinknormale Relation.
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).
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..
Beziehungen auf sich selber sind in Codd (und Nachfolger) nicht erlaubt
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"?
<class name="Category"
<!-- WICHTIGER PUNKT -->
<!-- WICHTIGER PUNKT -->
<!-- WICHTIGER PUNKT -->
<!-- WICHTIGER PUNKT -->
table="CATEGORY"
lazy="true">
<!-- Common id property. -->
<id name="id"
type="long"
column="CATEGORY_ID"
unsaved-value="null"
access="org.hibernate.auction.persistence.DirectSetAccessor">
<generator class="native"/>
</id>
<!-- lots of stuff. Gelöscht von Axel -->
<!-- Parent can be null for root categories. -->
<many-to-one name="parentCategory"
cascade="none"
outer-join="false"
foreign-key="FK1_PARENT_CATEGORY_ID">
<column name="PARENT_CATEGORY_ID"
not-null="false"
unique-key="UNIQUE_NAME_AT_LEVEL"/>
</many-to-one>
<!-- We use a Set for this bidirectional one-to-many. Batch fetching is
particulary interesting for this association: We expect that the
application will need much more childCategories if it accesses
one. Batch fetching can significantly improve fetching of the
whole category graph.
-->
<set name="childCategories"
cascade="all-delete-orphan"
inverse="true"
lazy="true"
batch-size="10"
access="org.hibernate.auction.persistence.DirectSetAccessor">
<key column="PARENT_CATEGORY_ID"/>
<!-- WICHTIGER PUNKT -->
<!-- WICHTIGER PUNKT -->
<!-- WICHTIGER PUNKT -->
<!-- WICHTIGER PUNKT -->
<one-to-many class="Category"/>
</set>