Die besten RDBMSe

Computer: Software & Programmierung Datenbanken allgemein
#1

Hallo,

die Frage ist vielleicht nicht so undifferenziert zu beantworten wie mir lieb wäre, aber welches ist das beste Datenbank System das zur Zeit verfügbar ist.

Mir geht es dabei im wesentlichen um die Performance einfacher Abfragen. Ich benutze seit längerem mySQL und bin eigentlich ganz zufrieden, wollte mich nurmal informieren ob es noch Server gibt die einfach aus gleicher Hardware mehr rauskitzeln. Interessant finde ich z.b. auch postgreSQL, habs zwar nur auf die Schnelle angeschaut, aber es bietet eben im Vergleich zu mySQL, das ja wirklich kaum was kann ne ganze Menge (Triggers, Views, etc.). Hat mal jemand damit gearbeitet? Wie ist so die Leistungsfähigkeit dieses Servers?
Was gibt es sonst noch?

Natürlich spreche ich gerade von günstigen / kostenlosen Systemen. Also eine Oracle Datenbank schaff ich mir nicth an, würde mich aber trotzdem interessieren was kommerzielle Systeme so zu bieten haben.

Danke
Bruno

#2

Also eine Oracle Datenbank schaff ich mir nicth an,
würde mich aber trotzdem interessieren was kommerzielle
Systeme so zu bieten haben.

Große, kommerzielle Datenbanken kauft man auf keinen Fall von der Stange und dann liefern sie plötzlich sagenhafte Performance, sondern dann sollte man sich gleich einen Spezialisten dazu kaufen bzw. mieten der an den - für die jeweilige Applikation richtigen - Schräubchen dreht und damit die Daten so richtig schön flutschen läßt. :smile:

Grüße, Robert

#3

…also schick mal Angebote :smile:

Wenn man Oracle Glauben schenken will, bieten sie das schnellste RDBMS an, das es gibt. Natürlich Hardware und Kohle vorausgesetzt.

Ein Kollege von mir war aber sehr von Informix angetan, da es im direkten Vergleich (auf der gleichen Maschine) um Klassen performanter war als Oracle. Natürlich auf die Anwendung bezogen.

Ich persönlich fand die paar Kleinigkeiten, die ich mit MySQL angefangen habe, auch angenehm schnell. Aber solange dort keine Transaktionen unterstützt werden, wird MySQL von mir nicht unterstützt :smile:

Gruß

J.

#4

Ich persönlich fand die paar Kleinigkeiten, die ich mit MySQL
angefangen habe, auch angenehm schnell. Aber solange dort
keine Transaktionen unterstützt werden, wird MySQL von mir
nicht unterstützt :smile:

mysql unterstützt keine transaktionen? das wusste ich noch gar nicht - hab bisher mit sybase gearbeitet. dabei wollte ich mysql mal ausprobieren… naja, dafür isses kostenlos :o)

gruß
tobias

#5

Aber solange dort
keine Transaktionen unterstützt werden

mysql unterstützt keine transaktionen?

Puh - das stimmt nicht! Seit Version 3.23 (22.01.2001) unterstützt MySQL tatsächlich Transaktionen (http://www.mysql.com/news/article-54.html). Werde ich demnächst mal ausprobieren!

Gruß

J.

#6

Hi,

Wenn man Oracle Glauben schenken will, bieten sie das
schnellste RDBMS an, das es gibt.

ich kann mir gut vorstellen, daß dem auch tatsächlich so ist - wenn man in den Terabyte-Bereich kommt, und selbstverständlich das DB-Layout optimiert. Anderen DBMSsen würde ich (auch mangels Erfahrung) derartige Datenmengen jedenfalls nicht anvertrauen, und Oracle schluckt sie ohne zu murren.

Natürlich Hardware und Kohle vorausgesetzt.

Vor allem sollte ein Experte vorausgesetzt werden. Ich vermute aber, das gilt für alle Systeme :smile:

Cheatah

#7

ähm auch auf die Peinlichkeit hin mich zu blamieren (obwohl ich schon ein wenig Erfahrung auch mit Oracle etc. gesammelt habe), wofür braucht man Transaktionen? bzw. was ist der Nachteil wenn mein DBMS dies nicht unterstützt.

#8

Hi,

ähm auch auf die Peinlichkeit hin mich zu blamieren (obwohl
ich schon ein wenig Erfahrung auch mit Oracle etc. gesammelt
habe), wofür braucht man Transaktionen? bzw. was ist der
Nachteil wenn mein DBMS dies nicht unterstützt.

Ein RDBMS speichert die Daten auf verschiedenen Tabellen, wobei Referenzen zwischen ihnen mindestens genauso wichtig sind wie die Daten selbst. Transaktionen halten so verteilte Daten konsistent, und zwar in mehrfacher Hinsicht:

  • Atomare Operationen: Es werden entweder alle Daten gespeichert oder keine (z.B. bei Abstürzen)
  • Lesekonsistenz: Während ein Benutzer die Daten schreibt, stehen sie für Abfragen eines anderen (genauer: einer anderen Transaktion) nicht zur Verfügung
  • Schreibkonsistenz: bei konkurrierenden Zugriffen erhält die Transaktion, die zu spät kommt, eine Fehlermeldung.

Du siehst, Transaktionen sind wichtig (ich vergesse hier aus dem Stehgreif bestimmt den einen oder anderen Vorteil). Für mich ist ein RDBMS erst durch Transaktionen verwendbar. Sicher gibt es die eine oder andere Anwendung, die ohne sie auskommt, aber mich wundert es, daß MySQL erst vor kurzem so grundlegende Dinge eingebaut hat.

Gruß

J.

#9

Anderen DBMSsen würde ich (auch
mangels Erfahrung) derartige Datenmengen jedenfalls nicht
anvertrauen, und Oracle schluckt sie ohne zu murren.

Hmmm, den Hinweis bringt Oracle als Seitenhieb zu IBMs DB2. Ich weiß keine genauen Zahlen, aber ich würde mich nicht wundern, wenn die Datenmengen bei DB2 im Durchschnitt größer wären (Stichwort Industrie, Banken, usw.). Auch von Informix hört man von großen Datenmengen.

Das mit dem Experten ist klar: die Systeme sollten nur verglichen werden, wenn sie vom jeweiligen Experten getunt worden sind.

Gruß

J.

#10

Transaktionen …

ähm auch auf die Peinlichkeit hin mich zu blamieren (obwohl
ich schon ein wenig Erfahrung auch mit Oracle etc. gesammelt
habe), wofür braucht man Transaktionen? bzw. was ist der
Nachteil wenn mein DBMS dies nicht unterstützt.

Guten Tach.

Als Ergänzung zu José : Mit Transaktionen ist, besonders bei verteilten Anwendungen, die Kontrolle über Datenabhängigkeiten besser gegeben.

Klassisches Beispiel : Der Buchungsvorgang bei der Bank. Überweisung von Konto A = Kontonummer prüfen, Kontostand prüfen, Betrag abbuchen. Auf Konto B = Kontonummer prüfen, Betrag zubuchen. Wenn Du den gesamten Vorgang in eine Transaktion packst, hast Du die Gewähr, daß nicht einseitig ab- und auf der anderen Seite nicht zugebucht wird (wenn zum Bleistift der Server der B-Bank mitten in der Transaktion abschmiert …).

Gruß kw

#11

Hi,

Für mich ist ein RDBMS erst durch Transaktionen verwendbar.

ACK. Alles andere erinnert mich fatal an den gleichzeitigen Zugriff auf eine begrenzte Zahl von Fleischstücken durch mehrere Krokodile…

Cheatah

#12

restore oder recovery
Aus DBA-Sicht ein neuer Aspekt:

Ueber den „normalen“ Betrieb hinaus sollte das Rdbms auch mit extremen Situationen klarkommen. Ein moegliches Szenario waere ein physikalischer Datenverlust (Festplattenausfall, etc.).

Ein kommerziell genutztes Rdbms muss nun die verlohrenen Informationen moeglichst exact wieder herstellen. Ich meine damit aber nicht nur das Wiedereinspielen der Bandsicherungen (Restore) sondern das Wiederherstellen von Daten durch Recovery, d.h. vom Zeitpunkt der letzten Bandsicherung bis zum Festplattenausfall.

Ich habe allerdings keine Ahnung, wer das alles wie gut kann. Oracle loest diese Problematik allerdings (imho) perfekt.

Ein weiterer Punkt (fuer kommerzielle Systeme) sollte die Frage sein : „Kann ich beim Rdbms-Hersteller in 5-10 Jahren noch Support / Schulung / Consulting bekommen ?“. Gerade das Beispiel Informix hat ja gezeigt, dass man sich nur auf wenige Konstanten verlassen kann.

Und eines noch : In einer Firma ist weder Linux noch MySQL noch sonsteine Software kostenlos. Ausbildung- und Einarbeitungszeit, Supportkosten und Ausfallbedingte Kosten fallen bei jeder Software mehr oder weniger an (Stichwort „total costs of ownership“). Bei manchen Systemen kommt dann eben noch die Lizensgebuehr dazu - ich kenne aber genug Beispiele, wo diese nur einen laecherlichen Teil des Gesamtbudgets ausgemacht hat.

Gruss Janus