Datenbank für Filialsystem

[Neumann]

Wir planen eine Datenbank, in der die Daten (Stammdaten und Bewegungsdaten von mehreren Filialen des jeweiligen Kunden gespeichert werden sollen und die mit den jeweiligen lokalen Datenbanken synchronisiert in dem Sinne, dass Stammdaten an die jeweiligen Standorte kommen und Bewegungsdaten in die Zentraldatenbank geschrieben werden.

Natürlich soll es auch Editier - und Auswertemöglichkeiten in der Zentrale geben.

Die Zentraldatenbank könnte so auf 50-100 GB kommen.

Ich würde dafür gerne Firebird nehmen, da ich damit gut zurecht komme und u.a. das Konzept der Trigger und Stored Procedures schätze und viel nutze.

Jetzt kam aber von einer Kollegin folgendes:

Die Firebird Datenbank hat

1. kein Pationierungsmechanismus, d.h. keine Methode zum Speichern von unterschiedlichen Daten auf unterschiedlichen Knoten

2. Kein Replikationsmechanismus, d.h. keine Methode zum reduntanten Speichern von Daten auf mehreren Knoten

3. Kein Konsistenzkonzept, d.h. eine Methode zur Sicherstellung der Konsistenz in verteilten Systemen

4. Keine Möglichkeit Strukturen nur im Hauptspeicher zu halten.

Hat sie wohl irgendwo gefunden.

Replikation gibt es natürlich, muss man was externes nehmen.

Die anderen Sachen hat wohl nur Oracle, ev. Hana. Ist die Frage ob die überhaupt relevant sind und was der Spaß kostet.

MariaDB steht im Raum, begeistert mich aber nicht wirklich.

[jobo]

Die Einwände sind vermutlich berechtigt, im Sinne fehlender Funktionalität. Die Frage ist, ob die Funktionalität gebraucht wird und was man dafür ausgeben will. Im Falle der professionellen Anbieter würde ich sogar noch weiter gehen und fragen, wie sehr kann man sich auf das Preis / Leistungsverhältnis verlassen, das man jetzt kauft.

Ein 50-100 GB Datenbank, braucht die Partitionierung?
Soll es ein firmeninternes System sein / werden / bleiben oder soll es ein Produkt sein? Wieviel Know How gibt es in eurem Haus für andere Systeme?

[Medium]

Was ist dein Vorbehalt gegenüber MariaDB? Wir haben die viel im Einsatz, in manchen Fällen auch mit Replikation (sogar gegenseitige Replikation unter gleichberechtigten Maschinen) und auch Partitionen, wobei letztere nur Table-Partitions sind um sehr datenreiche langfristige Logs im Zugriff etwas zu "entklotzen". Wir hatten in vielen Jahren auch bislang keine DBMS-begründete Ausfälle, das Ding ist super stabil. Und vor allem in Installation und Wartung vergleichsweise leichtgewichtig.

[Neumann]

Es soll für unser Kunden sein. Kann etwas kosten, aber sollte nicht so sein, dass die Datenbank schon einen 5-stelligen Betrag verschlingt.

Knowhow ist sonst nicht so doll vorhanden, etwas Mysql und MSSql.

[hstreicher]

Also IBExpert hat da eine Applikation für einen größeren Fialialbetrieb gebaut und wartet sie auch
mal am Mittwoch den virtuellen Stammtisch besuchen

mfg Hannes

[Neumann]

Ja bei dem virtuellen Stammtisch wollte ich schon mitmachen aber habe es bisher noch nicht geschafft.

Von der Applikation für den Filialbetrieb habe ich schon gehört. Finde ich natürlich interessant.

[Rainbow6]

Zitat von Neumann:

Knowhow ist sonst nicht so doll vorhanden, etwas Mysql und MSSql.

Warum nicht SQL Server Express für die Filialen?

Also die Fastfood Kette Subway hat ihr aktuelles Kassensystem so aufgebaut. Auf den Kassen läuft eine einheitlich konfigurierte SQL Server Express Instanz, und das läuft ziemlich problemlos.

Replikation kann soweit ich weis der „richtige“ SQL Server - den bräuchte man aber nach meinem Verständnis nur 1x für die Zentrale Datenbank.

Für eigene Zwecke habe ich schon eine „Replikation“ ausschließlich mit SQL Anweisungen und Linked-Servern über VPN realisiert - geht, ist aber aufwändig weil du eigene Skripte für jede Tabelle bauen musst.

Grüße
Daniel

[Bernhard Geyer]

Techniken wie Replikation sollte man nicht unterschätzen.
Hatten schon zwei CRM/Kundendatensysteme im Einsatz und bei beiden wurde kurz nach Einführung die Replationslösungen aus dem supporteten Funktionsumfang genommen.

Evtl. betrachtest du dein System als zwei getrennte (nur lose Verbundene) Datenquellen

Die Stammdaten.
Welchen Umfang haben diese? Welche müssen wirklich zu den Clients.
Ich könnte mir vorstellen diese nur als "readonly" XML/Text-Dateien für die Clients bereit zu stellen

Die Clientdaten
Wär es möglich das diese als "Plaintext"/XML/JSON/... vom Client zum Server übertragen werden und dann dort von
einer "Importerkomponente" in die zentrale Datenbank gepumpt werde. Müssen wirklich alle Filialdaten "1:1" für jede Buchung in
der Zentralen DB landen? Sind hier nicht "zusammengefaste" Daten sinnvoller und nur in Außnamefällen schaut man sie die Einzeldaten einer Filiale im Detail an?

Und von der DB-Größe:
100 GB ist heute nichts besonderes mehr. Wenn du jetzt nicht gerade "Echtzeitauswertungen" in höchster Komplexität sofort brauchst, reicht dir vermutlich ein "0815"-Server mit 16/32 GB RAM und einer kostenlosen Firebird/MySQL/MariaDB erstmal aus.

[Medium]

Zitat von Neumann:

Es soll für unser Kunden sein. Kann etwas kosten, aber sollte nicht so sein, dass die Datenbank schon einen 5-stelligen Betrag verschlingt.

Knowhow ist sonst nicht so doll vorhanden, etwas Mysql und MSSql.

Was meine Frage nur noch bestärkt.

[p80286]

MariaDB mag ja ein gutes System sein, kann ich nicht beurteilen. Aber ich habe den Eindruck das Neumanns Kunde nicht gewillt ist in das KnowHow seiner Mitarbeiter zu investieren. Bei einem Wissenstand der nahe 0 liegt ist der Aufstieg zur Administration immer recht hoch. Bei MariaDB vll. nicht so hoch wie bei einem Oraclemonster aber trotzdem nicht im Vorbeigehen zu erledigen.

Gruß
K-H


P.S.
Ich finde Bernhards Anmerkungen wichtig. DieWahl der DB ist da eher zweitrangig.