Ab wann 2 Datenbanken sinnvoll?
Bobby
- datenbank
0 King^Lully0 Bobby0 King^Lully0 Bobby0 King^Lully0 Bobby
Moin
mal eine allgemeine Frage von mir.
Ist es sinnvoll für ein Großprojekt mit zwei unterschiedlichen Datentypen (Communitydaten, Listing-Daten) 2 Datenbanken mit 2 Verbindungen anzulegen oder beiden Datentypen in eine Datenbank zu hinterlegen?
Ich dachte mir, das eventuell aus Performancegründen (reservierter Speicher je Verbindung(Sitzung)), die Verteilung beider Datentypen auf 2 DB's sinnvoll wäre. Was meint Ihr?
Gruß Bobby
Ist es sinnvoll für ein Großprojekt mit zwei unterschiedlichen Datentypen (Communitydaten, Listing-Daten) 2 Datenbanken mit 2 Verbindungen anzulegen oder beiden Datentypen in eine Datenbank zu hinterlegen?
Ich dachte mir, das eventuell aus Performancegründen (reservierter Speicher je Verbindung(Sitzung)), die Verteilung beider Datentypen auf 2 DB's sinnvoll wäre. Was meint Ihr?
Da fragst Du genau den Richtigen, den herausgestellten Aristokraten unter den DB-verwaltern, der, der nur Gott und dem Kaiser Rechenschaft schuldet.
Ähh, wo waren wir stehengeblieben, richtig, da war eine Frage. Wie lautete die Frage bitte? Wann zwei DBs einsetzen? Ist da ein RDBMS unterstellt? Oder gehts um verteilte Datenbasen, also auf verschiedenen Geräten oder zumindest von verschiedenen Diensten betreute Datenbasen?
Und was heisst denn hier "Datentyp"? INTEGER bspw. ist ein Datentyp. "Communitydaten" sind auch kein Datentyp, sondern eher die Bezeichnung eines zusammenhängenden Objektrudels (Tabellen etc.), also einer Datenbank.
Datenbanken verwalten miteinander verbundene Entitäten, diese werden per entity relationship model geformt und dann per FKs und PKs verzeigert. D.h. die Tabellen (Entitäten) gehören zusammen.
Gehören einige Entitäten offensichtlich nicht zu einem bestimmten Tabellenrudel, so kommt man typischerweise mit einer neuen DB.
Gerne auch auf demselben Gerät bzw. demselben RDBMS.
Was meinst Du jetzt genau mit Verbindungen und Performance?
Moin
Gehören einige Entitäten offensichtlich nicht zu einem bestimmten Tabellenrudel, so kommt man typischerweise mit einer neuen DB.
Gerne auch auf demselben Gerät bzw. demselben RDBMS.
Was meinst Du jetzt genau mit Verbindungen und Performance?
Naja. Ähm... hm... Nun erstmal überlegen. Also mit Performance meinte ich, ob es von Vorteil ist, das ein "Tabellenrudel" in der selben DB bei hohen Zugriffen auf das andere "Tabellenrudel" an Performance (Zugrifssgeschwindigkeit, bzw. Zeit der Auswertung) verliert. Und ob man diesen Effekt mit einer zweiten DB und der Auslagerung dieses zweiten "Tabellenrudels" umgehen kann.
Ansonsten erstmal Dank für die allgemeine Erklärung des DB-Gurus schlechthin.
Gruß Bobby
Was meinst Du jetzt genau mit Verbindungen und Performance?
Naja. Ähm... hm... Nun erstmal überlegen. Also mit Performance meinte ich, ob es von Vorteil ist, das ein "Tabellenrudel" in der selben DB bei hohen Zugriffen auf das andere "Tabellenrudel" an Performance (Zugrifssgeschwindigkeit, bzw. Zeit der Auswertung) verliert. Und ob man diesen Effekt mit einer zweiten DB und der Auslagerung dieses zweiten "Tabellenrudels" umgehen kann.
Die nichterforderliche Verteilung der Datenhaltung auf (zu) viele Objekte ist immer schlecht bzw. sehr schlecht.
Das gilt für Tabellen, Datenbanken, Datenserver und alle anderen Objekte.
Es sei denn, diese ist aus ganz bestimmten Gründen erforderlich.
Liegen solche vor? (Jetzt müssten handfeste Begründungen kommen, keinesfalls allgemeine Überlegungen, denn allgemein betrachtet ist die Sache klar.)
Moin
Es sei denn, diese ist aus ganz bestimmten Gründen erforderlich.
Liegen solche vor? (Jetzt müssten handfeste Begründungen kommen, keinesfalls allgemeine Überlegungen, denn allgemein betrachtet ist die Sache klar.)
Hm. Das war nun doch etwas zu allgemein. Mal ein Beispiel.
Ich habe 2 Bereiche auf einer Webseite. Einmal die Daten der Community (Chat, Messager usw.) und zum anderen ein Listung von Daten (die mit der Community nix zu tun haben).
Nun stelle ich für die verschiedenen Tabellenrudel Funktionen zur Verfügung, welche auf die DB zugreifen. Die Community wird z.B. mehr genutzt und die Zahl der Anfragen ist ziemlich hoch. Nun ist das Problem, das auch Anfragen für das Listing der 2. Datengruppe (Tabellenrudel) längere Antwortzeiten benötigen.
Ist es möglich mit der Trennung der beiden Tabellenrudel (Auslagerung auf je eine DB) die Antwortzeiten über die Funktionen welche auf die Listingdaten zugreifen zu minimieren? Oder hat dies keinen positiven Effekt?
Gruß Bobby
Ist es möglich mit der Trennung der beiden Tabellenrudel (Auslagerung auf je eine DB) die Antwortzeiten über die Funktionen welche auf die Listingdaten zugreifen zu minimieren? Oder hat dies keinen positiven Effekt?
Eine Auslagerung auf zwei DBs verlangsamt grundsätzlich den Datenzugriff, es gibt aber noch andere Auslagerungen, z.B. auf verschiedene Geräte, CPUs oder Festplatten. Dann wirds schneller.
Moin
Eine Auslagerung auf zwei DBs verlangsamt grundsätzlich den Datenzugriff, es gibt aber noch andere Auslagerungen, z.B. auf verschiedene Geräte, CPUs oder Festplatten. Dann wirds schneller.
Danke. Das war die Antwort die ich mit meiner Frage erhoffte. Schwere Geburt. :-) Also werde ich alles in eine DB packen, da ich keine Möglichkeit habe 2 Geräte, CPU's oder Festplatten zu nutzen.
Gruß Bobby