Datenbank für kleine/mittlere Datenmengen?

[Ganon]

Hallo.

In der Firma in der ich arbeite, suchen wir eine neue Datenbank, die unsere alte (Paradox) ersetzen soll.

Vorausschauend wollen wir die komplette Entwicklungsumgebung und auch Programmiersprache/system wechseln (zu viele Probleme mit altem, wird auch nicht mehr Weiterentwickelt, keine Fehlerbehebung).

Bevor wir uns auf eine Programmiersprache/system einigen, wollen wir erst mal verschiedene Datenbanken vergleichen, bzw. gucken was optimal ist. Optimal wäre natürlich komplett unabhängig von der Datenbank, aber mit irgendwas muss man die Software (netzwerkfähiges Warenwirtschaftssystem) ja mitliefern. ^_^

Nunja. Nun wollte ich mal fragen was ihr so empfehlen könnt, bzw. Vorschläge machen könnt.

Große Datensatzmengen sind nicht zu erwarten. Zur Zeit liegt der Durchschnitt so bei 100 000 Datensätzen in einigen Tabellen. Da stellt sich die Frage ob ein großer SQL-Server wie PostgreSQL8 oder MySQL5 nicht etwas unterfordert wäre, was sich aufgrund der Architektur dann negativ auf die Gesamtperformance auswirkt...

Gibt's vielleicht dafür entsprechend besser geeignete Datenbanken, die vielleicht weniger bekannt sind? Sollte unter Windows und Linux laufen.

Danke. :)

[Monger]

Wieviele (parallele) Zugriffe sind denn zu erwarten? Das ist imho das zweite große Kriterium für eine Datenbank.

[Ganon]

Also bisher so 1-15 Clienten sind zu erwarten. Klar, wenn ein Kunde mehr will... Aber das haben wir bisher nicht. Der Durchschnitt liegt bei uns zur Zeit bei 5-6.

Wie viele Zugriffe auf die Tabellen das im Endeffekt sind, weiß ich jetzt nicht. Zur Zeit sind wohl immer so ca. 5-10 Tabellen / Client geöffnet.

[Berni]

Wenn du sehr flexibel bzgl. der Datenbank sein willst, dann könntest du ja auch was mit J2EE und JDBC machen...allerdings ist J2EE insgesamt nicht gerade performant nach meinen Erfahrungen...

[Coda]

Schau dir doch mal SQLite (http://www.sqlite.org/) an.

[Ganon]

Ist SQLite mittlerweile Netzwerkfähig?

[Coda]

Nein, wird es auch vom Konzept her nie sein. Ich wusste nicht dass du das brauchst...

[clm[k1]]

Bei uns in der Firma setzen wir erfolgreich auf J2EE mit Spring und Postgres.
Beim Datenbankzugriff kommt Hibernate (http://www.hibernate.org/) zum Einsatz.

Die Anforderungen an unsere Systeme sind allerdings auch ungleich höher (15 Clients sind da vergleichsweise nichts)

...unser Chefentwickler sagt immer, er ist überglücklich, das wir auf Java setzen - mit C++ wäre er längst verzweifelt :D


clm[k1]

[Ganon]

Ich muss erst mal wissen was mein Chef nun will. Erst sagte er mir gleich: "KEIN JAVA, zu langsam", etc. pp. und letztens hieß es "Ich hab Java noch nicht abgschrieben".

Hmm. Naja... mal sehen. ;)

[clm[k1]]

Woher kommen eigentlich immer die Gerüchte Java wäre zu langsam?? :confused:


clm[k1]

[SgtTynis]

']Woher kommen eigentlich immer die Gerüchte Java wäre zu langsam?? :confused:

...von so mancher schlecht gemachten Swingoberflaeche. Im Kern ist Java im jedenfall nicht langsamer als z.B. das .NET Framework (ein paar einseitige werbewirksame Benchmarks mal ausgenommen).

[HellHorse]

Gibt's vielleicht dafür entsprechend besser geeignete Datenbanken, die vielleicht weniger bekannt sind?
Es gäbe noch Firebird (http://firebird.sourceforge.net/) und Ingres (http://opensource.ca.com/projects/ingres) die sich natürlich jeweils für die beste opensource Datenbank halten.

Da ihr ja in der Situation seid, dass ihr schon Daten habt sollte es ja nicht so schwer rauszufinden sein, wie gut sie in eurem Fall funktionieren.

[Trap]

Wenn du von allen deinen Kollegen für verrückt gehalten werden willst:
Schlag http://franz.com/products/allegrocache/index.lhtml vor ;)

[Ganon]

']Woher kommen eigentlich immer die Gerüchte Java wäre zu langsam?? :confused:

Anscheinend, weil es Java-Versionen gab wo es wirklich langsam war? ;) Weil es gab ja mal das Problem das Java/Swing nicht gerade die Kanone war. Sowas hält sich. ;)

@HellHorse

Zeit und Geld ist das Problem. ;) Aber danke für die Tipps. :)

@Trap

Kann man dieses "Ding" wirklich benutzen? ;)

[Demirug]

Wenn du auf deiner Liste keine Linux Kompatibilität hättest würde ich dir ja einen MS SQLServer vorschlagen. Der neue 2005er ist wirklich ein feines Stück Software geworden.

[Ganon]

Hmm. Ne, gerade im Bereich des Servers muss schon Linux-kompatibilität da sein, da wir auch in der Firma nur Linux-Server haben und das sich auch nicht so schnell ändert. ;)

[grakaman]

Wenn du auf deiner Liste keine Linux Kompatibilität hättest würde ich dir ja einen MS SQLServer vorschlagen. Der neue 2005er ist wirklich ein feines Stück Software geworden.

Auch 2000er ist schon ein hervorragendes Produkt. Den 2005er habe ich bis jetzt noch nicht groß angetestet :( Wenn der Preis zählt, hätte ich ja schon entweder die MSDE oder eben die neue Expressversion empfohlen. Aber er muss wohl laut Anforderung sowohl unter Windows als auch Linux laufen. Anscheinend haben sie mehrere Datenbankserver unter beiden Systemen laufen.

[Ganon]

Anscheinend haben sie mehrere Datenbankserver unter beiden Systemen laufen.

Bei Paradox ist es kein Server, sondern einfach nur die Dateiablage. Die Clienten greifen dann nur auf die Dateien zu.

Aber es ist bei uns halt ca. 50:50 mit den installieren Servern bei unseren Kunden. Die einen haben Windows, die anderen Linux.

[Demirug]

Auch 2000er ist schon ein hervorragendes Produkt. Den 2005er habe ich bis jetzt noch nicht groß angetestet :( Wenn der Preis zählt, hätte ich ja schon entweder die MSDE oder eben die neue Expressversion empfohlen. Aber er muss wohl laut Anforderung sowohl unter Windows als auch Linux laufen. Anscheinend haben sie mehrere Datenbankserver unter beiden Systemen laufen.

Hat Ganon ja gerade bestätigt. Nachdem was ich vom 2005er bisher gesehen habe bin ich froh das wir bei unseren Industrieprojekten nur Windows Server setzten und uns deswegen nicht einschränken brauchen. Ok ich bin vielleicht gerade etwas Euphorisch aber Microsoft hat mit dem 2005er einige unserer Probleme gelösst bei dennen wir immer etwas in Beträngniss gekommen sind.

[Trap]

@Trap
Kann man dieses "Ding" wirklich benutzen? ;)
Das war nur zum Teil als Witz gedacht, ich halte AllegroCache von allen Objekt-Datenbanken die ich kenne für die mit der besten Integration in die Programmiersprache. Bin allerdings kein Anwender davon, sondern hab es nur mal so ausprobiert.
Hab keine Benches gemacht (die Datenbank hat kein SQL-Interface, also müsste man Benches portieren...), aber laut Entwicklern ist es nicht langsamer als MySQL.

So gut die Datenbank auch sein mag, es dürfte schwierig werden jemand zu einer Datenbank die in ein Common Lisp integriert ist zu überreden ;D

[Ganon]

Ok ich bin vielleicht gerade etwas Euphorisch aber Microsoft hat mit dem 2005er einige unserer Probleme gelösst bei dennen wir immer etwas in Beträngniss gekommen sind.

Klar. Beschränkung auf eine Plattform ist schon leichter und macht auch viel weniger Probleme, aber man ist dann halt auf eine Plattform beschränkt, was andere Probleme schafft. ;)

Es kommen halt auch anfragen nach Linux-Versionen. Da OpenOffice auch immer mehr anklang findet, ist bei einigen Firmen auch der Wunsch komplett nach Linux zu wechseln sehr groß. Weiterhin ist die Konkurrenz auf anderen Plattformen noch eher klein, was weitere Vorteile bringt. :)

[grakaman]

Klar. Beschränkung auf eine Plattform ist schon leichter und macht auch viel weniger Probleme, aber man ist dann halt auf eine Plattform beschränkt, was andere Probleme schafft. ;)

Es kommen halt auch anfragen nach Linux-Versionen. Da OpenOffice auch immer mehr anklang findet, ist bei einigen Firmen auch der Wunsch komplett nach Linux zu wechseln sehr groß. Weiterhin ist die Konkurrenz auf anderen Plattformen noch eher klein, was weitere Vorteile bringt. :)

Das kommt auf deine Ansprüche und Fähigkeiten an. Für einfache Dinge wirst du mit jedem kostenlosen DBMS sicher gut bedient sein. Wer aber wirklich komplexe Logik in seine DB implementieren will, wer extrem leistungsfähige und gut skalierbare Server braucht, der greift bei der Implementierung zu schätzungsweise 50% auf DBMS spezifische Features zurück. Will damit eigentlich sagen, wenn du einmal gutes Wissen für ein DBMS hast, dann wechelst du eh nicht so schnell.

[Demirug]

Klar. Beschränkung auf eine Plattform ist schon leichter und macht auch viel weniger Probleme, aber man ist dann halt auf eine Plattform beschränkt, was andere Probleme schafft. ;)

Es kommen halt auch anfragen nach Linux-Versionen. Da OpenOffice auch immer mehr anklang findet, ist bei einigen Firmen auch der Wunsch komplett nach Linux zu wechseln sehr groß. Weiterhin ist die Konkurrenz auf anderen Plattformen noch eher klein, was weitere Vorteile bringt. :)

Das Problem haben wir nicht. Entweder wir haben sowieso freie Hand beim Betriebssystem weil wir Schlüsselfertig liefern oder die IT des entsprechenden Unternehmens besteht sogar auf Windows.

[Ganon]

Wir sind halt nur Software-Entwickler. Die komplette Hardware zu supporten, würden wir nicht schaffen. Verkaufen aber auch Hardware, wenn es angefragt wird... ("man nimmt was man kriegen kann" ;))

Da muss man sich halt an den Markt und an ein paar durchgeknallte Admins anpassen. ;) Ein Kunde hat sogar nen Solaris-Server. ;) Naja. Mal sehen.

Ich mach Chef *auf die Uhr guck* heute noch ein paar Vorschläge, wie man die Sache angehen kann. Er muss dann halt im Endeffekt sagen, welche Richtung. ;)

Ich wäre ja auch für Java oder halt Mono/dotGNU, aber Chef hat bedenken, wie die Zukunft bei denen aussieht...

[Gast]

http://www-306.ibm.com/software/data/db2/udb/db2express/ !?

[hacki_NA]

jo, wollt ich auch grade vorschlagen... DB2 Express-C..

[eXistence]

darf ich mal fragen was genau gegen MySQL spricht?

- frei verfügbar
- riesen Community
- für viele Systeme verfügbar

das Argument "zu groß" finde ich merkwürdig, da der server selbst relativ schlank ist vom Installations-Aufwand (verglichen mit einer "wirklich" großen DB, wie z.B. Oracle)

[Ganon]

darf ich mal fragen was genau gegen MySQL spricht?
- frei verfügbar

Nicht für kommerziellen Gebrauch.


das Argument "zu groß" finde ich merkwürdig, da der server selbst relativ schlank ist vom Installations-Aufwand (verglichen mit einer "wirklich" großen DB, wie z.B. Oracle)

Ja schon. Ist halt die Frage:
- Geschwindigkeit kleine Datenmengen
- Geschwindigkeit große Datenmengen

DB vs. DB in diesem Fall. Klar. Da hilft wohl nur testen...

Wie gesagt. Die Frage steht noch im Raum.

[eXistence]

Ich hab das zwar selbst noch nicht gemacht (und bin mir auch nicht sicher, wie mans genau macht), aber kann man bei MySQL nicht zwischen unterschiedlichen "engines" wählen?
Vielleicht gibts da ne Variante, bei der MySQL etwas besser mit euren Anforderungen harmoniert...

[Darkstar]

Hallo.

In der Firma in der ich arbeite, suchen wir eine neue Datenbank, die unsere alte (Paradox) ersetzen soll.Wir standen vor demselben Problem. Dank der Weitsicht unseres Chefs wurde bei uns Interbase durch Oracle ersetzt. Inzwischen unterstützen wir auch MS-SQL.Bevor wir uns auf eine Programmiersprache/system einigen, wollen wir erst mal verschiedene Datenbanken vergleichen, bzw. gucken was optimal ist. Optimal wäre natürlich komplett unabhängig von der Datenbank, aber mit irgendwas muss man die Software (netzwerkfähiges Warenwirtschaftssystem) ja mitliefern. ^_^Ich emfehle, als Programmiersprache Java zu nehmen. Für den Datenbankzugriff beschränkt man sich entweder auf die Teilmenge des ANSI-SQL-Standards, der von den gängigen Datenbanksystemen unterstützt wird (z. B. SQL-92 mit Teilen von SQL-99) oder man benutzt spezielle Komponenten, die dann die Umsetzung für das jeweilige benötigte Datenbanksystem vornehmen (so wie das schon erwähnte Hibernate).

Eine Lösung, die nur auf ein Datenbanksystem zugeschnitten ist, halte ich für wenig zukunftssicher. Genausowenig eine Lösung, die nur auf einer Betriebssystemplattform (z. B. Windows) funktioniert.Große Datensatzmengen sind nicht zu erwarten. Zur Zeit liegt der Durchschnitt so bei 100 000 Datensätzen in einigen Tabellen. Da stellt sich die Frage ob ein großer SQL-Server wie PostgreSQL8 oder MySQL5 nicht etwas unterfordert wäre, was sich aufgrund der Architektur dann negativ auf die Gesamtperformance auswirkt...Die Frage kann ich aus eigener Erfahrung mit nein beantworten. Selbst Oracle liefert bei kleinen Tabellen zügig ein Ergebnis. ;)

Der Ansatz J2EE + JDBC würde es auch ermöglichen, die gesamte Programmlogik auf den Server zu verlegen. Der Zugriff darauf könnte dann beispielsweise mit Thin-Clients oder per Web-Browser erfolgen. Das macht sich immer dann ganz gut, wenn die Arbeitsplatzrechner beim letzten (und vorletzen) Hardwareupdate übergangen wurden. Server sind von solchen Phänomenen meist nicht ganz so arg betroffen (Ausnahmen bestätigen die Regel).

[grakaman]

Eine Lösung, die nur auf ein Datenbanksystem zugeschnitten ist, halte ich für wenig zukunftssicher.

Ihr kauf euch also für teuer Geld ein Oracle RDBMS und verwendet dann nur ein winziges Subset? Wenn man IMO nur annähernd ernsthaft DB Entwicklung betreibt, verwendet man automatisch Herstellerspezifische Funktionen. Das fängt ja schon bei Kleinigkeiten wie Trigger (davor/danach), indizierten Views, Cursors, Errorhandling, Transaktionen (Savepoints für schnelles Recovern), Locking etc. an. Da gibt es dermaßen unterschiedliche Syntax zw. den Herstellern. Gewisse Dinge kann man Abfrageseitig z.B. durch Persistenz-Layer bzw. dynamisch generiertes Sql (ORMapper) abfangen. Aber das ist auch nicht der Weisheit letzter Schliff, weil das a Performance kostet, falls das z.B. über Reflection gelöst ist und vor allem, das ist viel wichtiger, man die Rechtekette bei bestimmten RDBMS nicht verwenden kannst. Wer wirklich absolute Sicherheit braucht, der wird niemals ein Select/Delete/Update/Insert Recht auf einer Tabelle zulassen, sondern lediglich die Executeberechtigung für ein Datenbankobjekt (ist z.B. beim MSSQL so). Binden tut man sich letztendlich sowieso an einen Hersteller. Die Frage ist dann imo eher welcher Hersteller ist seriös genug, bietet eventuell die beste Kompatibilität zu früheren Versionen, Preis spielt natürlich auch eine Rolle, Support und Entwicklerresourcen ebenfalls ist wichtig.

[Darkstar]

Ihr kauf euch also für teuer Geld ein Oracle RDBMS und verwendet dann nur ein winziges Subset?Ja! :)

Es gibt trotz dieses scheinbaren Widerspruchs Gründe, die für ein großes (und teures) RDBMS sprechen: Die EDV-Administratoren unserer Kunden verlangen es nämlich so. Bei denen braucht man gar nicht erst wegen MySQL oder PostgreSQL anzufragen. Meist besteht sowieso nur die Wahl zwischen Oracle und MS-SQL. Die Lizenzen zahlt im übrigen der Kunde.

Übrigens bieten inzwischen die großen RDBMS-Entwickler auch kostenlose Versionen Ihrer Datenbanken an oder stehen zumindest kurz davor.Wenn man IMO nur annähernd ernsthaft DB Entwicklung betreibt, verwendet man automatisch Herstellerspezifische Funktionen. […]All die Sachen, die da von Dir aufgeführt werden, sind entweder bei allen Datenbanken im gleichen Maße verfügbar (globale Transaktionen) oder lassen sich im Programm nachbilden (Trigger), nur mit dem Unterschied, daß man ohne Mehraufwand verschiedene Versionen einer Datenbank eines Herstellers oder verschiedene Datenbanksysteme unterstützen kann, was z. B. von unseren Kunden häufig gewünscht wird.

Wenn man freilich in einer vordefinierten Umgebung arbeiten kann, also z. B. die Server-Hardware immer selber mit ausliefert, dann kann man sich natürlich auf eine bestimmte Datenbank festlegen und dahingehend optimieren. Für solch relativ anspruchslose Programme wie Warenwirtschaftssysteme, wo meist der Server und die Datenbanksoftware vom Kunden vorgegeben wird und man möglichst viele potentielle Kunden erreichen will, macht solch eine freiwillige Beschränkung allerdings keinen Sinn.

[grakaman]

All die Sachen, die da von Dir aufgeführt werden, sind entweder bei allen Datenbanken im gleichen Maße verfügbar (globale Transaktionen) oder lassen sich im Programm nachbilden (Trigger), nur mit dem Unterschied, daß man ohne Mehraufwand verschiedene Versionen einer Datenbank eines Herstellers oder verschiedene Datenbanksysteme unterstützen kann, was z. B. von unseren Kunden häufig gewünscht wird.


Im Bezug auf Abfrage kann man das zum Teil nachbilden, gebe ich dir Recht. Aber alles andere im Bezug auf Performanceoptimierung, wo man also DB seitige Datenbankobjekte braucht (z.B. indexed Views, partitioned Views etc. etc. etc.) gibt es starke Abweichungen in den Implementierungen.
Übrigens, wer Integrität nicht auf DB Ebene, sondern App Ebene realisiert, der hat IMO ein vollkommen falsches DB Design und mit hoher Wahrscheinlichkeit auch schon mal Angriffspunkte.



Für solch relativ anspruchslose Programme wie Warenwirtschaftssysteme, wo meist der Server und die Datenbanksoftware vom Kunden vorgegeben wird und man möglichst viele potentielle Kunden erreichen will, macht solch eine freiwillige Beschränkung allerdings keinen Sinn.

Lässt sich drüber diskutieren, weil ein Warenwirtschaftsprogramm erstens sensible Daten enthält und je nach Mächtigkeit eben sehr hohe Transaktionen aushalten muss bzw. gerade da auf Performance optimiert werden muss (wenn z.B. gleich eine Order Applikation wie ein Webfrontend dran hängt und sehr hohe Orders pro Tag eingehen). Außerdem eigenet sich IMO ein Warenwirtschaftssystem auch gut für OLAP, womit du in dem Punkt auch schon mal auf Herstellerspezifische Tools bzw. Datenbank APIs angewiesen bist.

[HellHorse]

Ist zwar vermutlich zu spät, aber ev für jemand anderes:
http://www.heise.de/open/artikel/70100

[Ganon]

Danke für den Link. Zu Spät ist noch nix. ;)

[cope]

@Demirug
In welcher Firma arbeitest du?


Mein Vorschlag: Firebird -> openSource, für Win und Linux, standalone/embedded Lösung
Ich denke für euren Bereich eine ganz brauchbare Lösung.


Auf welche ORM Tools außer NHibernate setzt ihr noch?