SQL: Datenbankabfragen beschleunigen

Tabellen normalisieren

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Die Normalisierung von Tabellen scheint für einen deutlichen Geschwindigkeitsverlust verantwortlich zu sein. Aber auch hier geht es um die Details.

Transkript

Immer wieder gerne und ausfürhlich diskutiert bei relationalen Datenbanken sind die sogenannten Normalformen. D. h. wenn Sie Tabellen normalisieren in einer bestimmten Art schreiben, dann gelten ja diese Regeln, die sich Normalformen nennen. Nur gerade zur Wiederholung die 3 wichtigsten, ersten, nämlich die sogenannte Atomisierung, Sie dürfen nicht mehrere Daten-Inhalte in ein einziges Feld schreiben. Die zeite Normalform, die Redundanz. Sie dürfen nicht die gleichen Werte irgendwo doppelt speichern. Und schließlich die Historie. Sie dürfen eigentlich keine Werte überschreiben, wenn Sie alte Werte aufheben wollen, brauchen Sie mehrere Felder. Das nur so ganz kurz zur Erinnerung, wenn Sie also Tabellen-Design organisieren und entwickeln, dann müssen Sie sich um die Normalisierung kümmern. Und wer ein Beispiel wie dieses findet, dann ist es ein Original Beispiel aus einer Access Microsoft Tabelle, der entdeckt erstmal das da eigentlich ziemlich viele Normalformen schon verletzt sind. Bspw. hat die Person, die hier in den Kontakten gespeichert wird, offenbar nur eine einzige e-mail Adresse, nur ein einziges Telefon oder Mobiltelefon, denn all das befindet sich in dem Datensatz. Auserdem wird der Ort namentlich genannt und nicht per Referenz auf eine Nachschlage-Tabelle, denn typischerweise gibt es eine PLZ und anhand der PLZ, das wäre eine Möglichkeit daraus ein Nachschlagefeld zu machen. Anhand der PLZ lässt sich ein Ort ermitteln. Und zu einem Ort findet sich außerdem ein Bundesland oder Kanton, wie das gerade heißt und dazu wiederum gehört ein Staat oder ein Land oder Region. Das ist also eine hierarchische Beziehung. Und wenn Sie das in dieser Form schreiben, könnten Sie da völlig ohne Probleme eine PLZ mit einem falschen Ort und einem völlig falschen Bundesland und einem ganz anderen Staat angeben, weil die Tabelle eben nicht normalisiert ist. Das es also so ziemlich alles verletzt was man machen kann, eigentlich sollte das so aussehen. Die Namen enthalten wirklich nur noch im wesentlichen Daten, die sich mit der Person beschäftigen. Davon abhängig in ein zu eng Beziehung beliebig viele Kontaktdaten und selbst das hier liese sich noch verbessern, denn wenn ich eine zweite e-mail Adresse hab' aber nur eine Eintragung für's Telefon, dann sind da auch schon Leerdaten enthalten. Also hier in den Kontaktdaten kann man noch einiges verbessern. Aber hier, das Sie schon mal sehen, diese Hierarchie, die Adresse gehört zu einem Ort, der Ort gehört zu einem Bundesland, das Bundesland gehört zu einem Staat oder wo was und dann steht in dem Namen nur noch die Referenz auf den Ort und selbst die PLZ würde ich nicht benutzen, denn Sie wissen sicherlich in Deutschland sind die PLZ nicht so eindeutig wie man denkt. Zur selben PLZ gibt's unterschiedliche Ortsteile. In Niedersachsen bspw. um Friesoythe herum, da können Sie zur selben PLZ mehrere Ortsbezeichnungen kriegen. Es ist also nicht wirklich die eins zu eng Beziehung die man erhofft. Das alles wäre ein normalisiertes Daten-Modell und die Diskussion, die an der Stelle dann direkt losgeht, besteht darin, ist das vielleicht langsamer, weil das an so vielen verschiedenen Tabellen gespeichert ist, gibt's ja durchaus den Verdacht, dass so 'ne Datenbank das dann aus allen Ecken und Enden zusammen suchen muss. Ich habe deswegen beispielhaft hier in der Datenbank 2 Varianten erstellt. Einmal das Original so zu sagen, Tabelle VieleDaten und eins zu eng verknüpft Tabelle VieleUnterdaten. Und das selbe künstlich hergestellt in einer einzigen Tabelle wo natürlich dieser Teil der Daten vielfach vorkommt, wenn in den Unterdaten 5 abhängige Datensätze sind, dann steht hier fünfmal das gleiche drin. Aber es geht ja nicht um Daten Konsistenz, die werden nämlich jetzt verletzt, sondern es geht darum rauszukriegen ob es Geschwindigkeits-Unterschiede gibt. Und wenn ja, ob die zu Gunsten oder zu Lasten einer Normalisierung sind. Und Sie werden sehen, das hängt sogar davon ab, welcher Art die Verknüpfung ist. Es gibt also verschiedene Varianten, wenn ich das hier einmal schließe, dann kann ich in dem Formular z. B. prüfen wie das mit einer Verknüpfung ist, die mit einer Longzahl funktioniert. Das ist der Klassiker, den Sie eben gesehen haben. Ein Autowert ist typischerweise eine Longzahl und der Fremdschlüßel dazu ist dann natürlich auch eine Longzahl und wenn ich das mal einfach hier im Vergleich gucke, das ist die Verknüpfung zwischen 2 Tabellen, braucht ungefär 140 ms. Wenn ich das gleiche mit einem Text mache, also die Verknüpfung, das ich kann ich Ihnen gerne einmal eben zeigen, die Original Verknüpfung ist zwischen einem Autowert und einer Long-Fremdschlüssel-Referenz. Jetzt mache ich das gleiche in den gleichen Tabellen mit dem zusammengesetzten Namen. Das ist ein einziger Text und im Vergleich werden Sie gleich sehen auch mit 2 verschiedenen Texten. Das ist inhaltlich identisch, weil dieser Name sich aus den beiden zusammensetzt, aber der Aufwand ist größer so zu sagen. Es gibt ja durchaus häufig Verknüpfungen über mehrere Schlüßel, das lässt sich nicht immer vermeiden. D. h. nochmal zur Erinnerung, die Longzahl knappe 140 ms. Die Textverknüpfung, da kann man schon viel, viel länger warten, das wird über 1500 ms, also 1,5 s dauern, wenn ich das jetzt mit 2 Texten mache, dann dauert das nochmal bedeutend länger. D. h. das sieht eigentlich erstmal so aus als wäre Normalisierung und die damit verbundene Verknüpfung jetzt über 3 s, das ist nochmal das doppelte gegenüber 140 ms für eine Long-Verknüpfung. Es sieht also so aus, als wäre erstens eine Verknüpfung relativ teuer und natürlich eine Text-Verknüpfung unglaublich langsam. Teuer im Sinne von viel Zeit verbrauchend. Das gucken wir uns vielleicht nochmal in den wirklichen Detailzahlen an. Also wenn ich die Tabellen normalisiert habe oder eben nicht, dann gibt es die 2 Varianten. Wie gesehen, mit, in diesem Fall, einem Primär-Schlüßel, einem Autowert, über Long-Verknüpfung normalisiert in 2 Tabellen und das gleiche, das nennt sich Denormalisiert in einer einzigen Tabelle. Und das sieht erstmal so aus, wenn ich mir die Zahlen angucke normalisiert unter den standardisierung der Test Bedingungen jetzt nicht hier auf 'nem anderen Rechner ungefär 2,5 s, 2500 ms und alles in einer einzigen Tabelle ist doppelt so schnell. Das ist 28% und das sieht auf den ersten Blick einmal so aus, als ob das gegen die Normalisierung spricht. Da muss man sich aber dann schon ein bisschen genauer angucken wie die Details aussehen. Erstens ist die Normalisierung kein Argument das es schneller geht, sondern vor allem dass es richtig ist und Sie erinnern sich an mein Argument Date Korrektheit geht vor Geschwindigkeit! Also das kann schon mal erst kein Argument sein, wenn die Daten falsch sind aber schnell kommen, aber guckt Sie ruhig mal was passiert, wenn ich diese beiden Tabellen, wirklich beide abfrage oder nur eine davon. Die beiden Tabellen zusammen, haben Sie eben gesehen, fast 2,5 s, aber wenn ich nur eine davon abfrage, dann bin ich weit unter der Hälfte, ich bin sogar weit unter einem drittel bei 600 ms, 28%. D. h. wenn ich nur eine von den beiden Tabellen brauche, dann ist der Zeitgewinn enorm. Also von daher, das Argument kann nicht sein, die nicht- normalisierten Tabellen sein ein wenig langsam, sondern das Argument muss sein, erstens Sie müssen normalisieren damit die Daten in Ordnung sind, und zweitens, dann sollten Sie die auch mit Lonzahlen verknüpfen, auf gar kein Fall mit Texten und der Geschwindigkeitsgewinn ergibt sich dann wieder, wenn Sie auch nur eine der Tabellen abfragen. Sie haben eben gesehen, das Daten-Modell führt oft zu vielen, vielen einzelnen Tabellen. Eine Liste bspw. aller vorkommenden Orte ist viel, viel schneller aus 'ner normalisierte Tabelle, als aus der Original alles drinn Tabelle zu ermitteln.

SQL: Datenbankabfragen beschleunigen

Entdecken Sie, wo das Beschleunigungspotenzial für SQL-Datenbanken liegt und lernen Sie die Rezepte für bessere Performance.

2 Std. 15 min (39 Videos)
Derzeit sind keine Feedbacks vorhanden...
Exklusiv für Abo-Kunden
Erscheinungsdatum:25.03.2015

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!