Sonstiges > Infrastruktur
Glanz und Elend von RDBMS aus Sicht der Anwendungsentwicklung
Marinero Atlántico:
In diesem Hibernate-Mapping-File aus der caveatemperor Beispielanwendung von Gavin King / Christian Bauer geht deutlich hervor, dass Gavin King und Christian Bauer Tupel der Category Tabelle auf sich selbst in eine 1 zu n Beziehung stellen.
--- Code: ---<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>
--- Ende Code ---
Will hier jetzt jemand behaupten, Gavin King/Christian Bauer haben keine Ahnung von Datenbankmodellierung und haben Codd nicht verstanden ???
Semeaphoros:
Axel, das ist die falsche Frage, ob man von Datenbankmodellierung eine Ahnung hat, hängt eh nicht am relationalen Modell. Und selbst wenn man Codd verstanden hat, kann man solche Sachen machen, vorausgesetzt man weiss was und warum man es tut. Selbst Codd hat das Durchbrechen der Regeln grundsätzlich nicht verboten.
Marinero Atlántico:
Thomas erzeugt offenbar sein Datenbankschema automatisiert aus UML Diagrammen. Mit Hibernate habe ich das auch schon automatisiert aus Objekten hibernate-xml Dateien gemacht und daraus Datenbankschemen. Die Leute bei uns im Büro machen das auch sehr oft (mit Hibernate).
Ich hab sowieso Probleme mit dieser sogenannten "Strenge" von RDBMS.
Worin besteht diese Strenge?
Dass es überhaupt ein Datenmodell gibt, über das die Validität der eingegebenen Daten geprüft werden kann?
Ist das nicht vielleicht ein Vorteil?
Imho kann man ein Datenmodell schnell ändern, wenn man sich ein bischen auskennt.
Ich benutze z.B. ein AntScript, dass die entsprechenden Data Definition Language Befehle (DDL, sowas wie Create Table, Drop Table, etc.) gegen die Datenbank sendet und dann direkt mit Data Manipulation Language (DML, Insert/Select/Update) die Datenbank mit Beispieldaten füllt.
Genau dass lässt sich nämlich schon flexibel ändern. Das ginge auch mit bestehenden Datenbanken.
Axel
Marinero Atlántico:
Mit dem Äpfel und Birnenvergleich war natürlich zum Teil berechtigt.
Steht ein Programmierer vor einer Notes Datenbank, einer OODBMS oder einem RDBMS steht er vor verschiedenen Dingen.
Begreift man buzzword-kompatibel alles, was ein Entwickler von den eingespannten Ressourcen benutzt als Dienst, dann würd ich jetzt mal festlegen, dass alle 3 einen gleichen - sagen wir - Zentraldienst liefern:
Persistierung von Daten.
Was ist Persistierung von Daten?
Daten dauerhaft zugreifbar macht.
Jeder kann in einem kleinen Experiment feststellen, was persistente Daten sind:
1. Du stellst dich hinter jemanden, der in verschiedenen Anwendungen arbeitet.
2. Du ziehst das Kabel des Computers aus der Steckdose.
3. Der User fährt seinen Computer wieder hoch.
4. Alle Daten, die dem User von den vorherigen Eingaben fehlen waren leider nicht persistent gespeichert, sondern nur im ram. Alles was noch da ist, waren zu seinem Glück persistente Daten. Die sind noch da.
Persistente Daten werden auf die Festplatte geschrieben (oft in Form einer Datei). RDBMS , Notes oder OODBMS managed das.
Wieso muss diese Persistierung gemanaged werden?
Ein wichtiger Grund ist, dass viele Personen auf diese persitenten Daten lesend und schreibend zugreifen. Es versteht sich von selbst, dass diese Zugriffe irgendwie organisiert werden müssen.
Gut. Nachdem hier festgelegt worden ist, dass gemeinsamer schreibender und lesender Zugriff auf Daten im konkurrierenden Zugriff von mehreren Usern der zentrale Dienst von RDBMS, Notes und OODBMS ist, bleibt noch die Frage, welche zusätzlichen Dienste die 3 Obstsorten äh Systemtypen anbieten, anhand denen man die Systeme vergleichen kann.
Dazu später mehr.
Marinero Atlántico:
Zusätzliche Dienste sind aus meiner Sicht:
1. Security des Daten/Schemazugriffs: Autentifizierung/Autorisierung und Berechtigung der User bestimmte Operationen durchzuführen
- Daten löschen
- Daten einfügen
- Daten ändern
- Daten lesen
- Datenbankschema/Schablone ändern
- Code auf Datenbankserver laufen lassen
- Datenbank erstellen/löschen
2. Security der Datenübertragung (SSL, ssh, etc.)
3. Transaktionsunterstützung: Eine Transaktion sind mehrere Operationen gegen eine Datenbank in einer atomaren zusammengefasst. Und dies explizit vor dem Hintergrund des konkurrierenden Zugriffs mehrerer User. Atomistisch heisst ja auch, dass User A die Ergebnisse der transaktionalen Operationen von User B erst sehen darf, wenn die Transaktion ganz abgeschlossen ist (keine Zwischenergebnisse). Schliesslich ist es eine atomistische Operation.
4. Erweiterbarkeit der Datenbank (wie einfach sind Änderungen im Schema und wie kontrollierbar sind diese Änderungen--> vermeiden unerwünschter Seiteneffekte, die die Konsistenz der Daten gefährden)
5. Unterstützung von binären Daten.
6. Recovery Tools (Zurückdrehen bei inkonsistenten Zustand der daten).
7. Sprache, um Operationen in der Datenbank durchzuführen.
8. Validitätsüberprüfungen auf die Plausibilität der ankommenden Daten.
9. Möglichkeiten der Replikation. Wenn es etwa auf Grund der schlechten Leitungen zwischen Standort A und Standort B jeder Standort eine eigene Datenbank benötigt.
10. Robustheit/Failover/Clustering-Mechanismen
11. Integration mit anderen Plattformen
12. Reporting Tools.
Navigation
[0] Themen-Index
[*] Vorherige Sete
Zur normalen Ansicht wechseln