[SQL Design] Kann man am Tabellen-Design was verbessern?

[MyRealName]

Hallo Leute, hab mal 'ne kleine Frage...
Ich versuche in einer vorhandenen sehr grossen Software (1000+ Formulare) einen Dokumente-Container einzubauen, der geht auch ganz gut für verschiedene Teile schon. Jetzt hat aber jede Dokuemnt-Form eine eigene Liste, wo die Dokumente eines Typs gelistet werden mit ihren jeweiligen Übersichtsdaten.

Der Container muss ein paar "alte Daten" in eine ID wandeln und hat einige gemeinsame Daten für jedes Dokument (wie Status, Erstellunsgdatum, Nutzername etc).
Die plten Daten sind ein Unique Key für jedes Dokument (Felder: E, S, Tipo, Numero), das wird in ein DocID übersetzt.
Zusätzlich muss ich ein Stringfeld Clase mit 2 chars mitführen, welches die Klasse des Dokuments bestimmt (Wareneingang, Rechnung, Zahlungseingang etc).

Hier nun das Problem: die typische Abfrage der Listenansicht ist so wie "Zeige mir alle Einträge der Klasse soundso"

Also "SELECT * FROM DocCont WHERE Clase='OS' " zum Bsp.
Das ist natürlich nicht indiziert. Habe den Primärkey über "DocID", einen Unique über die Felder "E, S, Tipo, Numero", aber Clase kann halt tausendfach vorkommen.

Hat einer ne Idee ? Weil sowie ich 30000 Dokumente eines Typs habe, dauert esa schon auf meinem PC 1-2 Sekunden, ich möchte es im Netz erst garnicht probieren

Was ich mir überlegte ist eine Tabelle Hist_DocCont wo ich "alte" dokumente hinschiebe

[Union]

Du solltest tatsächlich die Datenmenge eingrenzen. Entweder durch ein Feld mit dem Du die Dinger ausblendend kannst oder über ein Datum:

Code:

"SELECT TOP 1000 * FROM DocCont WHERE Clase='OS' AND Acabada = FALSE AND Tramitado >= '2013-01-01' ORDER BY Numero"

Zusätzlich könnte zunächst ein auf dem Server schnell laufendes Count darüber erstellt werden und wenn dieses eine willkürlich gewählte Grenze überschreitet (hier 1000 Dokumente) dann dies im UI anzeigen.

Ausserdem würde ich versuchen auf jedes Query-Feld einen Index zu legen, wenn die Datenmenge so groß ist.

[BUG]

Auf jeden Fall ist es ein Problem, dass du alle Dokumente eines Typs anfragen willst.

Du könntest zum Beispiel die Anzahl der zurückgegebenen Dokumente beschränken und dann nur die Teilmengen der Dokumente anfragen, die gerade benötigt werden (vgl. Pagination). Es wäre ungewöhnlich, das du dem Nutzer wirklich zehntausende Dokumente gleichzeitig zeigen wolltest.

[Furtbichler]

Zitat von MyRealName:

Das ist natürlich nicht indiziert.

Warum nicht? Lege halt einen Index drauf.

Zitat:

Hat einer ne Idee?

Wofür?

Zitat:

Weil sowie ich 30000 Dokumente eines Typs habe, dauert esa schon auf meinem PC 1-2 Sekunden, ich möchte es im Netz erst garnicht probieren

Das kann über's Netz durchaus schneller gehen. Der Bottleneck hier ist einerseits der fehlende Index, und andererseits u.U. die Datenmenge, wenn nämlich neben den hier beschriebenen Spalten weitere Daten, insbesondere Binärdaten übertragen werden

Auch wenn meine Mitstreiter tolle Tipps parat haben, da ich nicht weiß, was Du optimieren willst (der Index muss aber sein), solltest Du zunächst beschreiben, was Du machen und was Du erreichen willst.

[jobo]

Ein Index auf einem Feld mit geringer Selektivität (clase?) wird wahrscheinlich nicht so viel bringen.
Was nutzt aber auch eine solche "Listenansicht"?
Wie wäre es, die "typische" Abfrage um eine typische Datumseinschränkung (variabel) zu erweitern und so per Default nur "aktuelle" Dokumente anzuzeigen? Ein Index auf dem Datumsfeld wäre da sicher effizienter.
Trennung von alten/neuen Daten:
Tabellen teilt man eigentlich nicht (selber). Besser das macht / kann die Datenbank, Stichwort Partitionierung.

Die Bedenken, die Abfrage im Netz (also auf dem Server statt lokal) laufen zu lassen, verstehe ich auch nicht unbedingt. Der Server sollte es besser können als Dein PC und ich hoffe natürlich, dass Du im Programmcode nicht wirklich alle 30 ts Datensätze lokal ziehst.

[MyRealName]

Datumsbeschränkung und Beschränkung der zurückgegebenen Register ist schon drin, aber intern muss firebird ja trotzdem ersatmal alle auswählen und dann dadrüber auswählen, oder ?

Normal suche ich nur die ersten 25-50 Dokumente (mit den letzten zuerst) und es wird nur nachgeladen wenn gescrollt wird, UniDAC macht das schon automatisch.

Aber Furtbichler hatte Recht, hab einen Index draufgelegt und brachte sehr viel. Hab wohl Index mit unique/primary Key verwechselt und dachte die müssten auch einen einzigartigen Schlüssel haben...

Danke an alle, Problem gelöst

[Furtbichler]

Zitat von jobo:

Ein Index auf einem Feld mit geringer Selektivität (clase?) wird wahrscheinlich nicht so viel bringen.

Statt eines Table-Scans wird ein Index-Scan durchgeführt => wesentlich weniger IO weil wesentlich weniger Daten. Nichts annehmen, sondern ausprobieren und dann wissen.

Zitat von MyRealName:

Aber Furtbichler hatte Recht, hab einen Index draufgelegt und brachte sehr viel.

q.e.d.