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:

Zitat von Neumann (Beitrag 1461844)

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:

Zitat von Neumann (Beitrag 1461844)

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.

[IBExpert]

Moin,

diesen Mittwoch wird der Stammtisch leider nicht klappen, da mich ein Stammkunde in der Spätschicht gebucht hat. Kommende Woche wird das aber wieder stattfinden.
Und wenn es um konkretes Projektpotential geht, dann gebe ich auch gerne "private" Sessions ;-)

Aber mal ganz im Ernst, es gibt 2 Varianten, so ein Projekt zu machen:

1. Wochen oder monatelang ausprobieren und hoffen, das der ausgesuchte Kram am Ende mit der Last bei dem Kunden klar kommt oder überhaupt irgendwie einsetzbar ist
2. Jemand fragen, der sich damit auskennt und mit dem zusammen das Projekt umzusetzen

Zu 1. sag ich nix weiter, aber wenn man mit uns 2. angeht, dann läuft das meistens wie folgt:
-Gemeinsamer Workskop (remote oder wo auch immer) um
-zu besprechen über welche Datenmengen und Arten wir reden (Standorte, Anbindungen, mit oder ohne DMS usw.)
-zu zeigen was geht, wie das geht, welche Hardware sinnvoll ist und welche Kosten zu erwarten sind

Wenn das passt, dann geht das weiter
-Detailvorgaben Datenbankstruktur innerhalb der Firebird Welt
-Oder mit anderen Worten, wir erklären dem Programmierer, was der als Metadaten Architektur benutzen soll, damit das multimaster Replikationssfähig ist
-Innerhalb dieser Vorgaben kann der Programmierer jeden Beliebigen create/alter/drop in seiner TestDB austesten und wenn er meint, das ist ok,
an unser System übergeben und nach entsprechendem ok von uns wird das an alle verteilt
-Anwendungsentwicklung machen wir auf Wunsch gegen Aufwand, aber in erster Linie steht dem Programmierer dabei die Entschiedung zu, ob er das alles selber Programmieren
will oder auf unser Know How zurückgreifen will

Wie viele Ziffern da am Ende das Projektvolumen hat, ist von sehr vielen Faktoren abhängig, aber wie du schon hoffst, das beginnt vierstellig. Wenn über so eine Software aber später zum Beispiel Lohnzeiten für 10000 Mitarbeiter abgerechnet werden müssen oder auch alle Warenbestände unternehmensweit in Echtzeit einsehbar sein müssen, dann wird dein Kunde sicherlich sehr begrenzt Freude dran haben, wenn die Daten zwar theoretisch synchron sein sollte,. es aber praktisch nicht sind. Ob du dafür nur die replikationsfähige MSSQL Server Vollversion an jedem Standort für je ca 15k€ Lizenz zzgl Hardware einplanst oder an Limits stößt in der MySQL/MariaDB Welt, das replizierte Datenbanken nicht größer sein dürfen als der Arbeitsspeicher, ist dann relativ egal, weil aus Kundensicht das ganze Projekt dadurch sicherlich schneller gescheitert ist als du denkst. Mit unserer Lösung kann ich real zeigen, das es zuverlässig funktioniert!

Weitere Details auch gerne auf Anfrage per email an [e-mail] gerne auch mit Gotomeeting Session Terminvorschlag (vormittags bin ich diese Woche recht flexibel)