Eine zentrale oder mehrere dezentrale DB?

[Erhard Henkes]

Wi geht man im globalen Maßstab an diese Frage systematisch heran: Eine zentrale oder mehrere dezentrale DB? Man möchte auf jeden Fall von zentraler Stelle auf alle Daten zugreifen können.

[nman]

Möchtest Du vielleicht das Problem bzw. die Anwendung näher beschreiben?

Lässt sich so nicht beantworten.

[Erhard Henkes]

Möchtest Du vielleicht das Problem bzw. die Anwendung näher beschreiben?

Es geht um Sammlung von Daten in den Fertigungseinheiten eines global operierenden Konzerns. Diese haben in ihrer Ganzheit zentrale Bedeutung. Kann nicht mehr dazu schreiben.

Lässt sich so nicht beantworten.

Mich interessieren typische Bedingungen unter denen der eine oder andere Fall von Vorteil ist.

[phlox81]

Kommt drauf an, welche "art" an Verwendung du als DB vorsiehst.

Wenn es nur darum geht Daten zu archivieren, kann man das natürlich trennen, und notfalls noch mit einer Zentralen DB synchronisieren, auch um Globale Statistiken zu haben.

Wenn es um Daten geht, die auf allen DBs immer gleichsein sollen, dann ist eine zentrale DB natürlich von Vorteil, bei mehreren Standorten kanns aber auch sinnvoll sein dann jeweils die SQL Statements auch auf die anderen DBs zu übertragen.

[hustbaer]

mal ganz grob...

lokal erfassen, zur zentrale rüber-replizieren, von dort noch ggf. zu weiteren standorten wo diese daten wichtig sein könnten. dann alle paar tage nen cube draus basteln, den kann man dann abfragen.

[Erhard Henkes]

..

[hustbaer]

sowas http://en.wikipedia.org/wiki/OLAP_cube

[Unix-Tom]

MySQL:
1.
Einen INSERT/UPDATE/DELETE SERVER
Viele SELECT CLIENTS.
2. Cluster

MSSQL

da gibt es viele Möglichkeiten
1. So wie bei MySQL
2. Replication mit vielen Masterservern. Jeder darf alles. Vorsicht mit Autoinc.
3. Cluster

MySQL und Replication rate ich ab. Nur Probleme. Insbesondere mit Sicherung.

[hustbaer]

Wenn es nur um Datenerfassung geht (kein UPDATE/DELETE), gibt es noch eine sehr einfache Möglichkeit:

* viele lokale Server für INSERT
* jeder lokale Server bekommt eine ServerID
* jede Zeile bekommt eine RowID per auto-increment
* Primary Key ist dann (ServerID, RowID)
* Transfer der Daten zum zentralen Server "manuell", d.h. über kleine Hilf-Programme, die einfach die neuen Daten zum zentralen Server rüberkopieren, und dann lokal als "kopiert" markieren (oder ggf. sogar lokal löschen, wenn die Daten lokal nichtmehr gebraucht werden)

Vorteile:
* man braucht keinen Cluster
* man muss sich nicht mit Replizierung rumschlagen (ist auch mit MSSQL nicht ganz einfache bzw. problemlos)
* skaliert gut
* man bekommt nicht sofort ein Problem wenn die Netzwerkverbindung zum zentralen Server gestört ist

[Unix-Tom]

Also ich hatte mit Repli. bei MSSQL noch nie Probleme.
Es funktioniert einfach ohne sich darum zu kümmern.
Sogar wenn man einen Server hat der nicht dauerhaft am Netz hängt oder es sich um Modemverbindung etc. handelt.
Die Repl was Du mit Hilfprogrammen beschreibst ist genau das was MSSQL und MySQL bei der Repl. macht ohne das man eigene Hildprogramme schreiben muss.
MSSQL kann sogar jeden Serer mit jedem Repl. egal wo der Insert passiert.
Man darf jedoch nicht nach Autoinc. gehen.

Ich kenne jett zwar Oracle nicht so aber ist vermutlich ähnlich wie MSSQL.
IBMDB rate ich ab. Habe da derzeit große Probleme eine DB auf einen anderen Server zu kopieren.
Selbst so einfach Dinge sind da nicht sehr einfach möglich ohne sich sehr sehr intensiv einzuarbeiten.

Wenn es ein kl. Projekt ist dann MySQL und wenn es professionell sein soll dann eben MSSQL oder vielleicht Oracle.
Die Kosten von MSSQL amortisieren sich sehr schnell.
Insbesondere wenn es dann um Backup geht. Da funktioniert BackUpExec perfekt. Auch mit Filestreams etc.
EIne DB mit mehreren Mill einträgen ist in wenigen Minuten wieder ON.
Ist bei MySQL nicht so.