Maximale Spaltenanzahl?

[Florian Johann]

Hallo!

Gibt es eine Anzahl von Spalten die man nicht überschreiten sollte, damit die Schnelligkeit der Datenbank nicht darunter leidet? Oder ist eine Anzahl von ca. 40 die ich jetzt habe kein Problem?

mfg
Florian

[Andreas Kosch]

Hallo,

nicht so sehr die Anzahl der Spalten, sondern die "Breite" eines Datensatzes sowie die Anzahl bzw. der Typ von indizierten Spalten spielt eine Rolle. Für die Performance eines SQL-Servers ist es wichtig, dass so viele Datensätze wie nur möglich auf eine "Datenbankseite" passen und der Datenbank-Cache so effektiv wie nur möglich wirkt. Lange Rede kurzer Sinn: Eine pauschale Aussage ist nicht sinnvoll

[Carsten Schmitz]

Hallo, ich habe jetzt auch eine Frage zu Spaltenanzahl bzw. sinnvoller Tabellenlogik, was gut in diesen Thread paßt.

Ich habe die Anforderung zu erfüllen, das zu einem Stamm und einem Währungspaar (alle 3 Felder sind Primärindex) verschiedene zusätzliche Informationen abgespeichert werden müssen.

Die Anzahl der zusätzlich abzuspeichernden Informationen ist abhängig von mehreren Laufzeiten (insgesamt 9 verschiedene). Für jede Laufzeit muß nun sowohl eine Marge als auch ein Limit abgespeichert werden.

Nun zur Frage, was ist sinnvoller:
* 1 Tabelle mit ca. 24 verschiedenen Spalten (3 Primärindexspalten, 9 Margenspalten, 9 Limitspalten und 3 weitere Spalten zum Speichern des jeweiligen Users)

* 2 Tabellen mit je ca. 15 verschiedenen Spalten:
Tab 1 mit 3 Primärspalten, 9 Margenspalten und 3 Spalten zum Speichern des Users sowie
Tab 2 mit 3 Primärspalten, 9 Limitspalten und 3 Spalten zum Speichern des Users

Die verwendete Datenbank soll übrigens Interbase bzw. Firebird sein. Priorität soll hier in erster Linie auf Schnelligkeit gelegt werden. Oder gibt es eine effektivere dritte Möglichkeit ?

Grüsse,
Carste

[Andreas Kosch]

Hallo,

>Priorität soll hier in erster Linie auf Schnelligkeit gelegt werden.

in diesem Fall würde ich beide Alternativen auf einer vergleichbaren Hardware (RAM/Festplatten) testen, wobei die Datenbank mit Testdaten bis auf die zu erwartende Größe gefüllt wird.

Wenn mehrere Anwender sehr intensiv Daten aktualisieren, wäre bei der 1-Tabellen-Lösung die Transaktionssteuerung einfacher. Die 2-Tabellen-Lösung hat immer dann Vorteile, wenn bei häufigen SELECT-Abfrage nur einige Spalten benötigt werden, die alle aus einer Tabelle stammen (d.h. die "unwichtigen" Spalten werden in die 2. Tabelle ausgelagert)

[Carsten Schmitz]

Ok, ich habe mir in der Zwischenzeit weitere Gedanken gemacht und bin zu einer folgenden interessanten Alternative angelangt.

Nachfolgend die 3. Variante:
1 Tabelle mit dem folgenden Primärindex (Stamm, Währungspaar und Laufzeit); also 4 Felder im Vergleich zu den beiden Varianten aus Posting 2

Diese Tabelle hätte nur noch ca. 9 Spalten (4 Primärindexspalten, 1 Limitspalte, 1 Margenspalte und 3 Spalten zum Speichern von User-Informationen).

Im praktischen Anwendungsfall hätte diese Variante wohl Vorteile, da eine SQL-Abfrage sofort zum gewünschten Ergebnis führt. Denn nach Angabe der 4 erforderlichen Input-Informationen (Stamm, Währung1, Währung2 und Laufzeit) würden die gewünschten Informationen sofort zur Verfügung stehen (Marge und Limit).

Nachfolgend eine theoretische Aufstellung der zu speichernden Felder bei einer Annahme von ca. 200 Kunden.

<PRE>
Datensätze Zu speichernde Werte
Variante 1: 200 4.800 (= 200 * 24)
Variante 2: 400 6.000 (= 2 * 200 * 15)
Variante 3: 1.800 16.200 (= 1.800 * 9)
</PRE>

Vorteil bei Variante 3 wäre m.M. nach eine schnellere Suche im Vergleich zu den beiden anderen Alternativen, da m.M. nach direkt die gewünschten Informationen zur Verfügung stehen.

Nachteilig dürfte eine hohe Datensatzanzahl der Tabelle sein, da so eine redundante Speicherung der verschiedenen Merkmale in Kauf genommen wird und die Tabelle schneller wächst als die beiden anderen Varianten.

In der Regel werden die Daten von 1-3 Anwendern gepflegt. Die Änderungen im Datenbestand dürften nur sporadisch erfolgen. In der Hauptzeit wird das System genutzt, um die eingegebenen Informationen (Marge- und Limit-Informationen) für einen Kunden bei vorgegebenem Währungspaar und Laufzeit schnell zur Verfügung zu haben.

Gehe ich daher richtig in der Annahme, das Variante 3 für diese Zwecke am sinnvollsten erscheint und ich auf zeitaufwendige Tests der beiden anderen Varianten verzichten kann ?

Grüsse,
Carsten

P.S. Eine Zwei-Tabellen-Lösung halte ich in der Form, wie ich sie in Variante 2 beschrieb, nicht sinnvoll, da bei dieser Variante in beiden Tabellen "wichtige" und "unwichtige" Informationen sind. Denn wenn eine Marge zu einer Laufzeit gesucht wird, dann wird auch das entsprechende Limit für diese Laufzeit benötigt.
Also bleiben jetzt nur noch Variante 1 und 3 übrig, wobei beides 1-Tabellen-Lösungen sind, so daß die Transaktionssteuerung einfach sein dürfte, oder