QUOTE (Magical @ Mi 9.06.2010, 12:59)im Rahmen der Planung einer neuen Website (wobei hier mehrere verschiedene Websites auch auf die Datenbankstruktur zugreifen sollen) bin ich jetzt am Überlegen, was aus Performancegesichtspunkten günstiger zu bewerten ist:
Option 1:
Alle Tabellen in einer Datenbank (wird eventuell etwas unübersichtlich, da auch nicht alle angeschlossenen Websites auf alle Tabellen zugreifen werden)
Option 2:
Mehrere Datenbanken (Allgemein (Daten die für alle Sites benötigt werden) + jeweils 1 pro zusammenhängendem Thema (ca 4-5 verschiedene)
Dazu kann man nur sagen: Es kommt darauf an
Innerhalb von Server-Daten habe ich eine Struktur, die Option 2 entspricht. Einige zentrale Datenbanken:
Eine mit Metadaten und einigen sehr großen gespeicherten Prozeduren, eine für temporäre Dinge, bsp. mit einigen Tabellen, die bei der Erstellung / dem Editieren von Nutzertabellen benötigt werden und die anstelle 'richtiger temporärer Tabellen' genutzt werden, eine für .NET - Assemblies.
Ansonsten hat jeder Kunde seine eigene Datenbank. Bestimmte gespeicherte Prozeduren, die direkt auf die 'Systemtabellen' innerhalb der Kundendatenbank zugreifen, gibt es auch in jeder Kundendatenbank, die sind also - aufs Gesamtsystem betrachtet - redundant.
Die eine zentrale Designüberlegung: Es muß jederzeit möglich sein, einen Kunden (= dessen Datenbank) rauszunehmen. Das spricht für eine solche Viel-Datenbank-Lösung. In deinem Fall: Wenn Du eine einzelne Domain später abgeben / verkaufen willst - was dann?
QUOTE (Magical @ Mi 9.06.2010, 12:59)... was aus Performancegesichtspunkten günstiger zu bewerten ist:
...
Macht es aus Performancegesichtspunkten Sinn, alles in einer Datenbank zu verwalten? Oder sind mehrere Datenbanken hier genauso gut (oder sogar besser)?
Für die Übersichtlichkeit wären mehrere Datenbanken auf jeden Fall günstiger, da es sonst schnell mehrere hundert Tabellen würden..
Auch da läßt sich kaum etwas auf die Schnelle aussagen. Bei genügend Arbeitsspeicher und hinreichend kleinen Tabellen sind in der Regel die Tabellen vollständig im Arbeitsspeicher, so daß die Performance ohnehin gut sein sollte.
Bei hinreichend großen Tabellen kann es Performanceprobleme geben, falls bsp. gefiltert und / oder sortiert werden soll und die Db-Software aus unterschiedlichsten Gründen keinen Index verwendet oder ein Index sogar zu einer Verlangsamung führt. Das ist aber in der Regel ein Problem, das erst ab mehreren 10.000 Datensätzen auftaucht.
Bei vielen Datenbanken und gleichlautenden Tabellen muß man umgekehrt sehr genau darauf achten, daß man die 'richtige Tabelle' adressiert. So nutzt eine zentrale Erzeugungsprozedur für Code in einer Kundendatenbank nur dann etwas, wenn sie es schafft, den Code auch genau in dieser Kundendatenbank (und nicht in einer anderen oder in der eigenen Datenbank des Codes) zu erstellen.
Sicherheit kann da ein sehr großes Thema sein, muß es aber nicht. Innerhalb von Server-Daten nutzt der Webserver einen einzigen Nutzer, der auf alle Datenbanken zugreift. Trotzdem kommt kein Nutzer an die Daten eines anderen Kunden ran, weil die Verteilung auf die Datenbanken über den Subdomainnamen läuft. Das läßt sich aber u.a. deshalb leicht handeln, weil verschiedenste Kunden auch nur die eine einzige, gemeinsame Webanwendung nutzen - und da ist das im Kern verankert.
Wenn also die einzelnen Komponenten später jeweils individuell programmiert werden sollen (womöglich von Externen), dann können die natürlich auf andere Datenbanken zugreifen.
Umgekehrt kämen die Externen bei einer einzigen Datenbank sofort an alles ran.
Innerhalb einer (Kunden-) Datenbank fahre ich dagegen sehr gut mit dem Prinzip, bsp. nicht für verschiedene Personentypen verschiedene Tabellen anzusetzen, sondern alle Personen in eine Tabelle zu packen, die um entsprechende Spalten ergänzt wird. Wenn später der Webserver-Client immer noch nach der richtigen Tabelle suchen muß, dann wird das nur unnötig kompliziert.
Grundsätzlich zum Design: Ich nutze ja den MS-SqlServer, arbeite von daher immer transaktionsorientiert. Für so ein Modell würde ich auf jeden Fall ein transaktionssicheres Backend (also InnoDB) nutzen. Denn wenn verschiedene Websites auf die gemeinsamen Daten zugreifen, dann kann es da immer kritische Abschnitte geben. Bei einem transaktionssicheren Backend sollte dann das Sperrproblem beim Sichern keine Rolle spielen - insofern wäre das für die Sicherung nicht mehr so wichtig.
