Vergleich von Datenbanken

[Kay]

Hallo,

ich will zwei Datenbanken (z.B. DB2 und Oracle) miteinander vergleichen. Ich bin gerade dabei, ein Benchmarking-Tool in Java zu entwickeln.
Folgende Eigenschaften prüfe ich bereits:

• Zugriffszeiten (Herstellen einer Verbindung zur DB, Ausführung eines SELECT-Befehls)
• Zeit zum Laden bzw. Speichern speziellen Datentypen, z.B. BLOB
  Welche Dinge könnten noch wichtig sein?

Vielen Dank für eure Vorschläge.

Viele Grüße, Kay

[_roro]

hi,

Welche Dinge könnten noch wichtig sein?

das Vakuum-Verhalten: Angenommen, eine Tabelle hat 20.000 Records. Diese werden alle 5 Minuten gelöscht und neu eingefügt. DELETE / INSERT deswegen weil ein UPDATE in 5 min nicht fertig wird.

Könnte u.U. wichtig sein bei der Wahl eines RDMS.

--roro

[Hamstar]

Welche Dinge könnten noch wichtig sein?

das Vakuum-Verhalten: Angenommen, eine Tabelle hat 20.000 Records. Diese werden alle 5 Minuten gelöscht und neu eingefügt. DELETE / INSERT deswegen weil ein UPDATE in 5 min nicht fertig wird.

Könnte u.U. wichtig sein bei der Wahl eines RDMS.

Ist "Vakuum-Verhalten" hier das Fachwort?   ;)

Zudem ist das von Dir geschilderte Szenario _kein_ üblicher Gebrauchsfall für RDBMSe, die typischerweise entweder "OLTP-mässig" (viele kleine transaktionale Prozesse) oder "OLAP-mässig" (Geschäftsdatenanalysen auf eigens dafür vorgesehenen Datenabsen) eingesetzt werden.

Aber gut "Massendatenbehandlung" ist sicherlich ein Leistungsmerkmal eines RDBMSes, es gibt wohl noch fast unzählige weitere, einfach mal in der Reklame für die RDBMSe nachschauen!

[hkl]

Hallo

Hallo,

ich will zwei Datenbanken (z.B. DB2 und Oracle) miteinander vergleichen. Ich bin gerade dabei, ein Benchmarking-Tool in Java zu entwickeln.
Folgende Eigenschaften prüfe ich bereits:

• Zugriffszeiten (Herstellen einer Verbindung zur DB, Ausführung eines SELECT-Befehls)
• Zeit zum Laden bzw. Speichern speziellen Datentypen, z.B. BLOB
  Welche Dinge könnten noch wichtig sein?

Vielen Dank für eure Vorschläge.

Viele Grüße, Kay

Crash Recovery

=> VORSICHT ! DAS HIER KANN DEN RECHNER UND DIE FESTPLATTEN ZERSTOEREN ! <=
( z.B. Durch Ueberhitzung )

Kochbuch
man nehme

• m tabellen gleicher Struktur die man

• gut mit diversen TEXT-Columns und FULLTEXT Indices darauf wuerzt
  (es soll ja deftig werden)

• AUTO_INCREMENT columns nicht vergessen.

• Zwei x,y davon verknuepfe man 1:n ON DELETE CASCADE, ON UPDATE CASCADE

• streue uber m-2 Tabellen einen TRIGGER ON INSERT der mit UPDATE auf den Primaerschluessel der unabhaengigen Tabelle x zielt

• m-3 Tabellen verkuepfe man baumartig 1:n NOT NULL

• eine den m-3 Tabelle lasse man ein m:n Relation repraesentieren

• man vakuire ggf. die Tabellen und schaffe jeweils einen TRIGGER der beim INSERT auf der unabhaengigen Tabelle in die abhaengige zielt und den eingefuegten Datensatz dorthin cloned ( natuelich unter Wahrung des constraints )

• Man clone die in allen Relationen unabhaengige Tabelle ( keine TRIGGER, keine CONSTRAINTS ),befulle den Clone mit einem Satz und dann ( INSERT INTO z(col1,col2) SELECT col1,col2 FROM z ) ca 20 mal nacheinander

• Man schreibe ein Skript das in einer Transaktion den Clone in das Original selektiert.

• Am Ende der Transaktion fahre man ein ROLLBACK

• WAEHREND des Rollbacks schalte man den TESTRECHNER hart aus.

• Hat man dies auf einem produktiven System gemacht, gehe man zum Arbeitsamt, gehe nicht ueber Los und ziehe nicht $4000 ein.

• Nach dem Recovery bstrachte man die Ruine.

Viel Spaas :-)

=> VORSICHT ! DAS KANN DEN RECHNER UND DIE FESTPLATTEN ZERSTOEREN ! <=
( z.B. Durch Ueberhitzung )

Gruss

Holger