1 DB viele Tabellen oder viele DBs mit Tabellen ???

Hallo zusammen,

ich überlege mit gerade die Vor- und Nachteile für folgende Situation.

5 Clients und ein Zentraler Server. Die 5 Clients geben getrennte Informationen in lokale eigene mysql-Datenbanken ein, was dann zum Zentralen Server übertragen wird (mysqldump) um dort Auswertungen zu generieren.

Nun meine Frage:
Soll ich auf dem Zentralen Server für jeden Client eine eigene Datenbank erstellen oder soll ich die Datenbank der Zentrale jeweils um Tabellen erweitern ???

Der einzige Unterschied der mir einfällt, dass wenn ich eigene Datenbanken nehme, dass bei einer zerstörten Datenbank der Rest noch funktioniert. Sont wüsste ich keine Vor- und Nachteile.

Mir ist aber aufgefallen, dass sämtliche Programme die auf Datenbanken basieren immer nur eine einzige Datenbank mit endlos vielen Tabellen verwenden. Z.b. Warenwirtschaftssysteme.

Die Auswertung der Zentralen Datenbank soll per php laufen. Wäre natürlich bitter wenn ich verschiedene Datenbanen nehme und am Ende geht es dann nicht.

Also die Frage konkret:

1 Datenbank mit vielen Tabellen oder lieber viele Datenbanken mit weniger Tabellen ???

Dankääääää

Hallo,

du hast dir die Frage im Prinzip selbst beantwortet.
Im Prinzip tuts eine, mehrere haben halt den Vorteil, dass du die erwähnte "abschusssicherheit" hast und das ganze etwas übersichtlicher ist. Außerdem kommt man sich mit den Namen der Tabellen nicht ins Gehege (wichtig wenn du keinen Einfluss auf die Clients hast).

Performancemäßig macht es keinen Unterschied, es sei denn du machst joins, die dann über die Datenbankgrenzen hinweggingen.

5 Datenbanken haben auch 5 mal Pflegeaufwand. Ein weiterer Nachteil: Bei automatisch vergebenen Werten, z.B. autoincrement für Schlüssel gibt es schnell massive Probleme bem Zusammenfassen von Daten, es sei denn, du nimmst die jeweilige Klientnummer immer mit in den Schlüssel. Dann kannst du aber auch gleich wieder alles in eine Datenbank packen. Wenn die getrennten Datenbanken allerdings auf den jeweiligen Clients liegen, sparst du etwas Traffic.

wenn du verteilte daten an einer stelle zusammenführst, solltest du das auch konsequent betreiben; dh.

1. jeder client erhält eine eigene kennung (clinetID)
2. die Tabellen auf den client-systemen haben die selbe struktur wie auf den host-system
3. die tabellen der clients werden am host-system _NICHT_ dupliziert, sondern innerhal der host-tabellen findet sich das kennzeichen clientID

Datenbestände parallel zu betreiben (egal ob in meheren db oder in duplitierten tabellen) erzeugt sehr bald einen fürchterlichen verwaltungs-overhead. ausserdem sind die daten nur schwehr auswertbar/vergleichbar.

Um probleme bei der schlüsselvergabe zu umgehen, ist es sinnvoll in jeden schlüssel die clientID einzubeziehen.

Ein weiterer Vorteil mehrerer Datenbanken wäre ein gewisser Datensicherheitsaspekt, denn wenn jeder ne eigene Datenbank hat, hat jeder nen eigenen Login mit dem er erstmal nicht an die Daten der anderen kommen sollte, von Databaselinks und sowas mal abgesehen, es ist halt isolierter.
Skalierbarkeit ist auch besser wenns verschiedene Datenbanken sind.

Aber deine Frage ist an sich schwer zu beantworten wenn man überhaupt nicht weiss, was du genau vorhast. Sollen alle Clients die selbe Art von Daten schicken, d. h. wird ein und die selbe Tabelle in jeder Datenbank vorkommen oder wird jede Datenbank verschieden aussehen? Solle die Statistiken in genau gleicher Art und weisse über alle Daten der verschiedenen Clients gehen oder nur einzel über die Daten pro Client oder soll für jeden Client eine eigene Statistik gefahren werden? Wie erweiterbar soll das ganze sein? Wie sensibel sind die Daten? Etc...

Evtl. (sehr wahrscheinlich sogar das bessere) tuts auch echt eine Datenbank mit einer Tabelle wo alle ihr Sach reinschreiben und halt vermerkt wird was von wem ist. In einer Datenbank für jeden Client ne eigene Tabelle mache, würde ich eher nicht, schon gleich dreimal nicht, wenn diese Tabellen alle gleich aussehen müssen, dann muss man bei einer Änderung womöglich alle ändern, bei verteilten Datenbanken das selbe, bringt halt nur was wenn wirklich jeder Client individuell ist oder das ganze recht sicherheitskritisch ist oder evtl. Performancegründe (Skalierbarkeit) dafür sprechen...

Datensicherheit über das Anlegen mehrer datenbanken zu realisieren ist zwar möglich aber idR. nicht wirklich sinnvoll. Es macht nur dann sinn, wenn die einzelnen anwender nicht über eine spezielle applikation sondern direkt via sql auf die daten zugreifen.

Ist eine App dazwischen, ist es deren Aufgabe Zugriffe zu regulieren bzw. Berechtigungen durchzusetzten.

Hmm, man nehme einen Client an, bei dem die Parameter für die Datenbankverbindung, also etwa auch das Passwort, in einer Konfigurationsdatei, im Klartext, hinterlegt sind.
Wenn nun mehrere dieser Clients die von unterschiedlichen Benutzern verwendet werden auf ein und die selbe Datanbank zugreifen kann jeder dieser Nutzer theoretisch aus der Konfigurationsdatei die Parameter auslesen und dann ggf. mit einem SQL-Client auf die Datenbank und da in den Daten aller Benutzer rumpfuschen, völlig unerheblich was der Client da ggf. noch prüfen würde, er hätte genaussoviel Rechte auf den Datenbankobjekten wie sie der Client auch hätte, und der Client hat quasi die Rechte für alle User zusammengefasst, weil er dem Datenbankmanagementsystem gegenüber als nur ein Benutzer auftritt.
Lösung 1, die Verbindungsparameter hartkodiert in die Clientsoftware, dann ist das schwerer, aber nicht unmöglich auszulesen oder eben mehrere Datenbanken, dann kanns einem egal sein, ob der der sonst den Client benutzt jetzt mit nem nativen SQL-Client auf die Datenbank geht, er kann sich ja nur in seine Daten pfuschen...

I. d. R. ein vernachlässigbares Szenario, aber ggf. durchaus mit einzubeziehen in die Überlegungen. Kommt halt drauf an was man will, wie immer...

Zitat:

---

Zitat von sticky bit

.... Kommt halt drauf an was man will, wie immer...

---

und eben da hüllt sich der op in schweigen... :o

Ich kenn sowas aus dem fernsehn - streng geheimer Regierungsauftrag... :rolleyes:

Im SQL-Standard sind auch Namepsaces vorgesehen (heißt da SCHEMA). Damit hast Du eine Gruppierungsebene unterhalb der Ebene "Datenbank". Ich weiss nicht ob MySQL Schemas unterstützt, aber bei Oracle ist das die übliche vorgehensweise: eine Datenbank, aber pro Applikation ein eigenes Schema.

Der Hauptnachteil von mehreren Datenbanken ist, dass Abfragen/Joins über Datenbankgrenzen hinweg nur über eine Krücke (DATABSE LINK) möglich sind. Und dass mehrere Datenbanken mehr Rechnerressourcen brauchen (was aber bei Oracle wohl schlimmer ist als bei MySQL oder PostgreSQL).

Meines wissens nach nicht.
Aber wozu gibts denn Prefixes?
In MaxDB arbeiten wir jedenfalls trotz Schema-Unterstützung nur mit Prefixen als Namespaces, was auch wunderbar klappt.
Zugriffsrechte-Steuerung gehört meiner Meinung nach auch mehr in die Anwendung als in den DB-Server.