Neue Datenbank

[delphirocks]

Meine Erfahrungen mit DBs liegen schon ein paar Jaehrchen zurueck.

Oracle ist teuer, schwierig zu admistrieren und sehr ressourcenintesiv. Dafuer aber full featured und die Stored Procedure Language (PLSQL, ein Ada Dialekt) ist um einiges besser als bei Postgres oder speziell Firebird.

Postgres kann fast alles, was Oracle und SQL Server koennen, kostet nix und ist bekannt fuer seine hohe Code Qualitaet. Eine Besonderheit sind spezielle GIS Features, die DB wird deswegen in der GeoInformatik Szene auch sehr viel eingesetzt.

MySql nehm ich her, wenn ich eine leichtgewichtige DB haben will, die mehr oder weniger nur als Datenstore dient.

Firebird hat ein paar komische Eigenschaften (z.B. mehrere Dialekte), ausserdem ist die Stored Procedure Sprache sehr gewoehnungsbeduerftig. Ein Vorteil ist allerdings, dass es auch eine serverless Option gibt, dh. man greift per Dll einfach auf's Datenfile zu, was fuer offline Szenarien ziemlich interessant ist.

Den MS Sql Server kenne ich am wenigsten. Bei mir hatte der immer irgendwelche Macken, wobei das wahrscheinlich am Benutzer und nicht an der Software selbst lag

Wirklich auffallen tun die Unterschiede aber nur bei riesigen Datenmengen. Da kann es dann z.B. sein, dass Oracle oder der SQL Server automatisch einen sehr guten Queryplan verwenden, waehrend du bei Firebird eventuell die Abfrage umschreiben musst.

NoSql Datenbanken wie MongoDB wuerde ich mich bei businesskritischen Anwendung eher nicht einsetzen. Wobe ich clusterfaehige Datenbanken wie Cockroach schon interessant finde. Aber gerade bei Geschaeftsdaten sollte man lieber auf Altbewaehrtes setzen, finde ich.

[Ghostwalker]

Zitat von delphirocks:

NoSql Datenbanken wie MongoDB wuerde ich mich bei businesskritischen Anwendung eher nicht einsetzen. Wobe ich clusterfaehige Datenbanken wie Cockroach schon interessant finde. Aber gerade bei Geschaeftsdaten sollte man lieber auf Altbewaehrtes setzen, finde ich.

Warum ? Gerade hier zeigen sich die Stärken von NoSQL-DB's (Thema: Big Data). Und wird auch bereits eingesetzt (z.B. GitHub). Die Clusterfähigkeit ist hierbei meist direkt in der DB-Server-Software integriert (auch MongoDB soweit ich weiß) und läuft recht stabil und zuverlässig. Bei MySQL z.B. benötigt man hier eine (recht teure) Software um sowas zu realisieren und läuft soweit ich weiß auch nicht wirklich stabil.

Bei der Frage welche Datenbank benutzt werden soll, sollte man sich, denk ich, erstmal ein paar Eckpunkte überlegen:

- Welche Datenmengen kommen zusammen ?
- Wieviele User sollen darauf zugreifen ?
- Wird eine Volltextsuche benötigt ?
- Wie ist die Struktur der Daten ? (einheitlich fixe Struktur oder doch eher unteschiedlich, evtl. Dokumente)
- Was darf das ganze (Software+Hardware) kosten ?
- Welche Software soll auf die DB zugreifen können ? (evtl. unterschiedliche Programmiersprachen im Einsatz)

[Thomas Feichtner]

Hier nochmals einige Eckpunkte:
Wir haben ein ERP-Programm und eine Campingplatzverwaltung. Das sind Fat Client Programme.
Außerdem greift ein weiters Programm (Xml-Server) darauf zu. Dieser läuft als Dienst und ist für Zugriffe z.B. für WebApp's, Importprogramme, Webshops, usw im Einsatz.

- Welche Datenmengen kommen zusammen ?
-> Hier kann die Positionstabelle von den Geschäftsfällen schon mal bis zu 5 GB haben.
-> Eine weiter Tabelle zwar von den Spalten her klein, aber hier werden Dokumente gespeicherte kann schon mal 60 oder mehr GB haben.

- Wieviele User sollen darauf zugreifen ?
-> Je nach Kunde von 1 bis zu 100 Usern

- Wird eine Volltextsuche benötigt ?
-> ja hatten wir bisher mit unserem ADS im Einsatz und möchte ich eigentlich nicht missen.

- Wie ist die Struktur der Daten ? (einheitlich fixe Struktur oder doch eher unteschiedlich, evtl. Dokumente)
-> Die Struktur ist bei den Kunden zu 85% gleich, jedoch hat jeder Kunde meistens noch individuelle Felder -> also keine fixe Struktur!

- Was darf das ganze (Software+Hardware) kosten ?
-> Bisher haben wir für die DB pro User ca. 160,00 verlangt
-> Die Softwarekosten hängt natürlich vom Produkt und anzahl der Arbeitsplätze ab. Da kann es zwischen 2000,00 und 70.000,00 ausmachen

- Welche Software soll auf die DB zugreifen können ? (evtl. unterschiedliche Programmiersprachen im Einsatz)
-> Wie schon gesagt unser ERP bzw. Campingplatzverwaltung (beides Fat Clients) und unser Xml-Server (kann man sich als REST-Server vorstellen).
-> Programmiersprache wird Delphi bleiben. Jedoch wer weiß was in ein paar Jahren kommt. Wobei hier man wahrscheinlich dann einen N-Tier Programm macht.

- Datensicherung
-> Bisher benötigte man einen exclusiven Zugriff oder man erstellte ein Backup

[mkinzler]

Sollte problemlos mit beiden der DBMS funktionieren.
Fulltext gibt es bei FireBird nur mit Zusatzprodukten oder händisch.
Für die Dokumente wiederum wäre FireBird besser geeignet.

[delphirocks]

Zum Thema NoSQL: es kommt immer darauf an, was genau man damit abbilden will. Aber ich nehm' mal an, dass die Daten wichtig sind, konsistent sein muessen und nicht verlorengehen duerfen. Dann wuerde ich zumindest von MongoDB die Finger lassen.

Einer meiner Freunde hat mit seiner Firma auf CouchDB gesetzt, weil da das Feature der Synchronsation mit mobilen Geraeten bereits eingebaut war. Das Ergebnis war, dass die Performance hinten und vorne nicht gepasst hat und sich CouchDB als Mega Kruecke herausgestellt hat. Die sind dann auf Postgres zurueck, was mit einem Riesenaufwand verbunden war.

Anonsten sieh dir einfach an, wie gut der Support fuer die Datenbank ist. Also z.B. wieviele Buecher usw. du auf Amazon zu dem Thema findest - auch was z.B. High Availability usw. anbelangt.

Ich wuerde auf Postgres oder wenn's fuer den Kunden moeglichst einfach sein soll, auf MySql/MariaDB setzen.

[jobo]

Zitat von mkinzler:

..
Für die Dokumente wiederum wäre FireBird besser geeignet.

Interessant! Was macht Firebird da?

[jobo]

Zitat von Thomas Feichtner:

Hier nochmals einige Eckpunkte:..

Das sieht relativ harmlos aus. ERP spricht m.E. eher gegen nosql Varianten.

Was die Programm Landschaft angeht sehe ich derzeit 3 Programme, also Clients aus Perspektive der DB. Mit einer Neuentwicklung (n tier) wären es 4.
Würden die alle auf einen Server zugreifen oder wäre ein Server nur für die Datenhaltung einer Anwendung zuständig? Es sieht nach heterogener App Landschaft aus oder?

Praxis:
Wie wäre es, wenn du einfach mal einen Test machst.
Ein Datenbankserver oder 2 (Firebird und Postgres) ist schnell aufgesetzt. (am schnellsten als VM)
Datenexport per SQL soll ADS ja können.
Zunächst nur die Scripte des Datenmodell.
Das dann auf den neuen Servern einspielen und erstmal einfach Fehler zählen / beheben, solange bis alle Tabellen da sind. Dann Daten einspielen.

Alternativ das ganze mit dem Tool / Scripten, mit denen Ihr Euer System selbst aufsetzt.

Man kann lange und viel suchen, recherchieren, die Praxis ist meist recht individuell. Könnte mir vorstellen, dass es sehr hilfreich ist.
Selbst wenn Ihr Euch am Ende natürlich gegen ein oder mehrere Systeme entscheidet, sammelt ihr sicher wertvolle Erfahrungen. Ist also m.E. erstmal kein rausgeworfenes Geld.

[mkinzler]

Zitat von jobo:

Zitat von mkinzler:

..
Für die Dokumente wiederum wäre FireBird besser geeignet.

Interessant! Was macht Firebird da?

Blobs werden in einem eigenen Bereich der Datenbank gespeichert. Ihre Größe ist nicht beschränkt.

[p80286]

Zitat von mkinzler:

Zitat von jobo:

Zitat von mkinzler:

..
Für die Dokumente wiederum wäre FireBird besser geeignet.

Interessant! Was macht Firebird da?

Blobs werden in einem eigenen Bereich der Datenbank gespeichert. Ihre Größe ist nicht beschränkt.

da hat mir ein Kollege über die Schulter geschaut, "Da gibt's doch keinen Unterschied!?" Interessant wenn zwei Personen das gleiche sagen, aber etwas unterschiedliches meinen!

Gruß
K-H

[jobo]

Zitat von p80286:

Interessant wenn zwei Personen das gleiche sagen, aber etwas unterschiedliches meinen!

Oder wenn es sogar 3 Meinungen gibt!

In Pg gibt es 3 Varianten sogenannte BLOBS zu speichern.
1 Type Text speichert BLOBS bspw mime codiert in der Tabelle
2 Type ByteA speichert uncodiert, Daten werden mit Fetch gemeinsam geholt, max value size 1GB
3 Type OID (Large Objects) uncodiert, gespeichert in Chunks in einer Systemtabelle, max value size 2Gb

Wir arbeiten idR mit 1 oder 2, komfortabel ist der mime codierte Export, sprich Transport von Dateien per Text Insert, Update, Delete
3 nutzen wir nicht, Zugriff per Streaming.

Wie sich das in der praktischen Nutzung bemerkbar macht/unterscheidet kann ich nicht sagen. Variante 1 hat natürlich durch das codieren einen Overhead.