Große Tabelle vs mehrere Datenbanken

Hallo,
Ich hab eine art Gruppensystem und frage mich was für die performance besser ist. Eine Datenbank dafür aber sehr große tabellen oder mehrere Datenbanken und kleine tabellen.
Bei mehreren Datenbanken würde man meistens auf 2 zugreifen müssen.
Wie weit sinkt die Perfomance wenn die Tabellen größer werden, gibts dazu statistiken oder änliches.

Grüße
XzenTorXz

Moin, XzenTorXz,

Performance beruht auf intelligentem DB-Design, nicht auf der Größe von Datenbanken oder der Anzahl von Tabellen (oder umgekehrt). Wenn ich einen Satz suche, dessen Suchfeld nicht indiziert ist, fahre ich schon kleine Datenbanken vor die Wand. Abgesehen davon: Klein und groß sind relativ - erstmal absolut und dann in Zusammenhang mit dem DBMS.

Wie weit sinkt die Perfomance wenn die Tabellen größer werden,
gibts dazu statistiken oder änliches.

So eine Untersuchung ist mir in 25 Jahren noch nicht begegnet. Na sagen wir mal, ich habe sie bislang nicht vermisst.

Gruß Ralf

Ok ich danke dir erstmal für deine antwort.
Bedeutet das soviel wie eine abfrage in einer DB mit 1 mio einträgen ist gleich schnell wie eine abfrage mit 100 einträgen (wenn die ergebnisse gleich sind) ?

Gruß
XzenTorXz

Hi!

Bedeutet das soviel wie eine abfrage in einer DB mit 1 mio
einträgen ist gleich schnell wie eine abfrage mit 100
einträgen (wenn die ergebnisse gleich sind) ?

sie kann schneller sein, muss aber nicht. Kommt halt aufs
Design an.

Naja, also wenn die Indizes vernünftig gestaltet sind läuft es beim Execution Plan auf dasselbe hinaus, egal, ob 100 oder 100 Mio. Datensätze abgelegt sind …

Ich verstehe aber vor allem nicht, warum „viele“ Datenbanken „kleine“ Tabellen haben, „wenige“ Datenbanken jedoch „große“ Tabellen … hier setzt mein Verständnis (aus knapp 20 Jahren DB-Erfahrung) aus …

Grüße,
Tomh

Moin, Tom,

Ich verstehe aber vor allem nicht, warum „viele“ Datenbanken
„kleine“ Tabellen haben, „wenige“ Datenbanken jedoch „große“
Tabellen … hier setzt mein Verständnis (aus knapp 20 Jahren
DB-Erfahrung) aus …

meins auch. Meine Neugier ist in dieser Hinsicht allerdings sehr begrenzt.

Gruß Ralf

Erstmal danke für die antworten.

Der User braucht nur bestimmte datensätze aus einer datenbank, d.h. er würde max. 0,01% der daten in einer datenbank brauchen. Deshalb hab ich überlegt für jede gruppe eine datenbank zu machen, damit hat man viele datebanken und weniger daten darin hat. (Die datebankstruktur bleibt dabei gleich).
Aber wenn die größe relativ egal ist, kann ich das auch in eine db hauen.

Gruß
XzenTorXz

Moin, XzenTorXz,

Aber wenn die größe relativ egal ist, kann ich das auch in
eine db hauen.

Kriterium ist nicht die Größe, sondern das Datenmodell: Alle Tabellen, die miteinander zu tun haben, gehören in eine gemeinsame Datenbank. Sollten sich dann Probleme ergeben, so liegt es meist gar nicht an der Größe, sondern am mangelhaften Design. Erst wenn das ausgeschlossen bzw. behoben ist, wird es Zeit, sich Gedanken zur Aufteilung zu machen.

Gruß Ralf

Morgen!

Alle
Tabellen, die miteinander zu tun haben, gehören in eine
gemeinsame Datenbank.

Hm, also ich habe in meinen (Oracle-)Datenbanken Tabellen, die haben absolut nix miteinander zu tun; nicht nur in der selben DB, sondern sogar im selben Schema und meist sogar dann im selben Tablespace (das macht das Ganze sogar noch performanter)

Grüße,
Tomh

Moin, Tomh,

Alle Tabellen, die miteinander zu tun haben, gehören
in eine gemeinsame Datenbank.

Hm, also ich habe in meinen (Oracle-)Datenbanken Tabellen, die
haben absolut nix miteinander zu tun;

und? Die Diskussion ging nicht darum, was alles in einen Topf kann (prinzipiell alles), sondern was dafür oder dagegen spricht, mehrere Töpfe anzulegen.

Gruß Ralf

Hi!

sondern was dafür oder dagegen
spricht, mehrere Töpfe anzulegen.

Dagegen: administrativer Aufwand (Datenabgleich, Berechtigungen, Datenpflege, Objektpflege, …)

Dafür: ?

Grüße,
Tomh

Hallo,

In diesem Fall wäre es angezeigt, sich mal in das Konzept der Partitionierung einzuarbeiten

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]