Der Query an sich

Question

Hallo!

Bei den Bestellungen zum Beispiel macht es Sinn, eine Auswahl nach Bestellnummer aufsteigend anzubieten. Aber der Nummernkreis wird so klein sein, dass man schon nach ein paar Jahren spätestens wieder von vorne anfangen muss. Da kann man den Vorrat im technischen Schlüssel so groß machen, dass man erst nach 30 Jahren wieder von vorne anfangen muss und dass man wegen des technischen Schlüssels die richtige Reihenfolge der Bestellungen hat. Dann ist der Datensatz mit dem kleinsten technischen Schlüssel der letzte Datensatz, der interessant ist, weil er schon längst abgehandelt ist. Also könnte man in DESCENDING Reihenfolge die Daten einlesen, um nur wenig mehr als die interessierenden Datensätze einzulesen. Dafür muss man wissen, welches der technische Schlüssel des ältesten Datensatzes, der noch nicht erledigt ist, ist. Denn sonst kann es sein, der Nutzer merkt gar nicht, da gibt es einen Datensatz, den man noch bearbeiten muss. In der Physik kann man viel damit anfangen, dass, was vorwärts geht auch rückwärts geht. Aber bei der Optimierung von Abfragen ist es ein Unterschied, ob man ASCENDING oder DESCENDING angibt. Wenn man eine Abfrage hat erstellen lassen, wäre eine Idee, dieselbe Abfrage, aber beginnend bei einem anderen Datensatz noch einmal ausführen zu können. Schön wäre auch, dass man weiß, wenn man einen Index erstellt hat, dass SQL genau diesen Index verwendet. Wenn man die ganze Datenbank in ein Dataset einliest (was bei dem Kundenstamm eines Fitnesscenters durchaus geht), habe ich auch gleich die Idee mit einem zweiten Dataset die Daten für die Anzeige in allen möglichen Formen aufzubereiten. Aber bei 40.000 Datensätzen wird man wohl schon in der richtigen Reihenfolge die Daten direkt aus der Datenbank ohne intern umzusortieren einlesen müssen.

Klaus Kühl

Answer 1

Hallo Klaus,

und was willst Du uns damit sagen?

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

Answer 2

Hallo Klaus,
um einen Algorithmus zu entwickeln, muss man die Details in möglichst kleine Einheiten/Aktivitäten zergliedern. Das vermisse ich In Deinen Darstellungen.

Bezüglich Bestellungen sollte jede Bestellung neben dem Inhalt der Bestellung eine Bestellnummer, diverse Datumsangaben (Bestelldatum, Realisierungsdatum usw.) und eine Zustandsangabe haben. Nur für die Nutzung im Programm sollte jeder Datensatz eine eindeutige Identifikation haben, z.B. einen Autowert oder eine GUID. Diesen Wert sollte der Anwender niemals sehen. Was Du mit technischen Schlüssel bezeichnest, kann ein beliebiger Wert sein, der unabhängig von den Mindestangaben einer Bestellung erstellt wird. In den Schlüssel können bei Bedarf auch Teile der Mindestangaben einfließen.

Die angezeigte Reihenfolge der Bestellungen hängt in erster Linie von der Arbeitsweise und den Aufgaben des Anwenders ab. So kann es beispielsweise von Interesse sein, alle nicht realisierten Bestellungen mit der am längsten nicht bearbeiteten Bestellung zuoberst anzuzeigen. In diesem Fall wird in der Abfrage nach dem Status der Bestellung gefiltert und nach Bestelldatum aufsteigend sortiert. Der technische Schlüssel wäre bei dieser Anzeige sekundär. Um zu wissen, welche unbearbeitete Bestellung zuletzt erfasst wurde, braucht man nur die Sortierfolge umzustellen.

In SQL Anweisungen sollte das Programm außer bei Suchabfragen immer nur mit der internen Identifikation arbeiten (vor allem bei Updates).

Auch ein Einlesen der gesamten Datenbank in ein DataSet ist keine gute Idee. Das erfordert u.U. sehr viele Ressourcen und macht damit das Programm langsam bis zum Absturz wegen unzureichenden Ressourcen. Die Idee mit mehreren DataSets ist dagegen gut. Für jeden Prozess, den das Programm realisiert, sollte ein eigenes DataSet genutzt werden. In das DataSet werden nur die im konkreten Prozess wirklich benötigten Datensätze und Spalten gehalten.

---

--
Viele Grüsse
Peter Fleischer (MVP, Partner)
Meine Homepage mit Tipps und Tricks

Answer 3

Hallo!

Mit dem technischen Schlüssel meine ich die ID des Datensstzes, die in SQL ein Integer-Wert ist und automatisch vergeben und hochgezählt wird. Da das ein Integer- Wert ist, kann man aber nur so viele verschiedene Datensätze im System haben, wie es der Zahlenvorrat eines Integers hergibt. Bei wirklich großen Datenmengen könnte man aber in zehn Jahren definitiv den ganzen Datenvorrat aufgebraucht haben, so dass - wenn man nach elf Jahren eine Sicherung wieder einspielt - es sein kann, schon wegen der ID kann man da nicht die Datenbank, zu der die Daten gehören, nutzen kann. Wenn man diese ID im OrderBy- Statement verwendet, sollte man schon gleich die richtige Reihenfolge der Datensätze haben, wenn diese ID immer aufsteigend bzw. absteigend ist. Bei SQL wird der Programmierer keine Ahnung haben, welchen Algorithmus SQL bei der Abfrage verwendet, weil SQL die Abfrage von sich aus optimiert. Wenn man nicht die ganze Datenbank einlesen will, braucht man ja alle benötigten Datensätze gleich in dem richtigen Zusammenhang und in der richtigen Reihenfolge. Dafür muss man einen komplexen Query auf die Datenbank loslassen. SQL optimiert zuerst diese Abfrage und liest dann die gewünschte Zahl von Daten ein. DA kann es sein, der Nutzer hat dann die eingelesen Datensätze abgearbeitet und will nach dem gleichen Schema noch mehr Daten bearbeiten. DA weiß man schon, welche Abfrage man verwendet, aber auch dass  man mit einem anderen Startwert bzw. zuerst einzulesenden Datensatz man weitermachen muss. In diesem Fall wäre es vielleicht schön, wenn dann SQL nicht noch einmal sich dieselbe Abfrage überlegen müsste, sondern gleich damit beginnen kann, die Daten einzulesen.

Vielen Dank

Klaus Kühl

Answer 4

Hallo Klaus,

wäre es möglich, den Text so zu schreiben, dass man das auch ordentlich lesen kann? Ein paar Absätze würde dem Ganzen sicherlich gut tun.

Zudem fehlen mir in beiden Postings die Fragen!? Oder bezweckst Du etwas anderes mit den Postings? Falls ja, was denn?

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

Answer 5

Hi Klaus,
ein Integer hat einen Wertevorrat von ca. 2 Milliarden, 200 Mio pro Jahr in 10 Jahren, 500.000 pro Tag bei 365 Tagen, 400 neue Datensätze pro Minute bei einem Arbeitstag von 24 h. Wenn Du wirklich solch gewaltige Datenmengen zu verarbeiten hast und eine Erschöpfung des Wertevorrates erwartest, solltest Du den Autowert gleich auf bigint stellen. Dann wären das ca. 15 Milliarden Datensätze je Sekunde bei 24 Stunden je Tag, 365 Tage pro Jahr, um nach 20 Jahren den Wertevorrat zu erschöpfen.

Eine Sortierung nach ID entspricht in den wenigsten Fällen dem von Anwender erwarteten Verhalten, da der Anwender diese interne ID weder sieht, noch beeinflussen kann. Sortiert werden sollte nach den verständlichen Werten wie Datum.

Bezüglich Blättern (Verarbeitung einer weiteren Menge von Datensätzen, nachdem bereits eine Menge verarbeitet wurde) gibt es verschiedene Techniken, je nachdem, was erwartet wird. Gerade bei Deinen vielen erwarteten Datensätzen (400 pro Minute) ist wichtig zu entscheiden, ob nach jedem Blättern die Ergebnismenge neu gebildet wird oder auf eine temporär zwischengespeicherte Menge zurückzugreifen ist. Bei Neubildung der Ergebnismenge kann es schnell passieren, dass Datensätze von ersten "Blatt" wieder im zweiten "Blatt" erscheinen, weil zwischenzeitlich neue Datensätze hinzugefügt wurden, was beim Blättern nach 5 Minuten bei Deiner Datenmenge 2000 Datensätze sein können.

Damit der SQL Server nicht bei jedem Abruf einen neuen Ausführungsplan erstellen muss, sollte bei solch gewaltigen Datenmengen generell mit Prozeduren gearbeitet werden. Das werden beim Einlesen der nächsten Portion (beim Blättern) der vorhandene Ausführungsplan genutzt und ggf. auch schon zwischengepufferte Daten schnell abgerufen.

---

--
Viele Grüsse
Peter Fleischer (MVP, Partner)
Meine Homepage mit Tipps und Tricks

Answer 6

Dann werfe ich noch mal das Stichwort Partitionierung in den Raum, mit dem man z. B. aktive Partitionen (aktuelles Jahr/Monat) von weniger genutzten Partitionen trennen kann.

Einen schönen Tag noch,
Christoph
--
Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu