Normalisieren vs. Denormalisieren von Datenbanken

Die Datenbanknormalisierung ist eine der heiligen Kühe der Anwendungsentwicklung. Jeder grundständige Programmierkurs, den Sie belegt haben, oder jedes Buch, das Sie gelesen haben, predigt wahrscheinlich die Bedeutung von Normalisieren von Datenbanken.

Es ist an der Zeit, diese Binsenweisheit in Frage zu stellen. Manchmal ist es in Ordnung, Ihre Datenbank zu denormalisieren!

Wann sollten Sie normalisieren?

Die Datenbanknormalisierung schützt die Integrität Ihrer Daten. Es ist in vielen Fällen eine großartige Idee, und Sie sollten Start jedes Datenbank-Design-Projekt unter Berücksichtigung der Normalisierung. Wenn Sie Ihre Datenbank normalisieren können, legen Sie los!

Die Quintessenz ist, dass du sollen Normalisieren Sie Ihre Datenbank, es sei denn, Sie haben einen wirklich guten Grund, dies nicht zu tun. Normalisieren ist normalerweise eine solide Designpraxis. Es reduziert redundante Informationen, optimiert die Leistung und verringert die Wahrscheinlichkeit, dass Sie Datenintegritätsprobleme, die sich daraus ergeben, dass dieselben Daten in verschiedenen Ecken Ihres Computers gespeichert sind Datenbank.

Einige gute Gründe, nicht zu normalisieren

Es gibt jedoch einige gute Gründe, Ihre Datenbank nicht zu normalisieren. Schauen wir uns einige an:

1. Joins sind teuer. Die Normalisierung Ihrer Datenbank beinhaltet oft das Erstellen vieler Tabellen. Tatsächlich können Sie am Ende leicht eine Abfrage erstellen, die Ihrer Meinung nach fünf oder zehn Tabellen umfasst. Wenn Sie jemals versucht haben, einen Fünf-Tisch-Join zu machen, wissen Sie, dass es im Prinzip funktioniert, aber in der Praxis ist es mühsam langsam. Wenn Sie eine Webanwendung erstellen, die auf Multiple-Join-Abfragen für große Tabellen angewiesen ist, finden Sie sich möglicherweise wieder denken: „Wenn nur diese Datenbank nicht normalisiert wäre!“ Wenn Sie diesen Gedanken in Ihrem Kopf hören, ist es ein guter Zeitpunkt, darüber nachzudenken denormalisierend. Wenn Sie alle von dieser Abfrage verwendeten Daten in einer einzigen Tabelle zusammenfassen können, ohne Ihre Datenintegrität wirklich zu gefährden, sollten Sie es tun! Seien Sie ein Rebell und denormalisieren Sie Ihre Datenbank. Sie werden nicht zurückblicken!
2. Normalisiertes Design ist schwierig. Wenn Sie mit einer komplexen Datenbank arbeiten Schema, werden Sie wahrscheinlich feststellen, dass Sie wegen der Komplexität der Normalisierung mit dem Kopf gegen den Tisch schlagen. Als einfache Faustregel gilt: Wenn Sie den ganzen Tag damit verbringen, herauszufinden, wie Sie in die vierte Normalform übergehen können, treiben Sie die Normalisierung möglicherweise zu weit. Treten Sie zurück und fragen Sie sich, ob es sich wirklich lohnt, weiterzumachen.
3. Schnell und schmutzig sollte schnell und schmutzig sein. Wenn Sie nur einen Prototyp entwickeln, tun Sie einfach, was schnell funktioniert. Wirklich. Es ist in Ordnung. Schnelle Anwendungsentwicklung ist manchmal wichtiger als elegantes Design. Denken Sie daran, zurückzugehen und Ihr Design sorgfältig zu prüfen, sobald Sie bereit sind, die Prototyping-Phase zu verlassen. Der Preis für ein schnelles und schmutziges Datenbankdesign besteht darin, dass Sie es möglicherweise wegwerfen und neu beginnen müssen, wenn es Zeit für die Produktion ist.
4. Wenn Sie eine NoSQL-Datenbank verwenden, traditionelle Normalisierung ist nicht wünschenswert. Entwerfen Sie Ihre Datenbank stattdessen mit dem BASE-Modell, das weitaus fehlerverzeihender ist. Dies ist nützlich, wenn Sie unstrukturierte Daten wie E-Mails, Bilder oder Videos speichern.

Einige Worte der Vorsicht

Die Normalisierung der Datenbank ist im Allgemeinen eine gute Idee. Sie sollten versuchen, die Prinzipien der Normalisierung zu befolgen, wenn dies sinnvoll erscheint. Wenn jedoch alle Indikatoren darauf hindeuten, dass die Normalisierung zu komplex für die Implementierung ist, sollten Sie einen Ansatz in Betracht ziehen, der die Arbeit erledigt und gleichzeitig Ihre Daten schützt.

Und schließlich: Wenn Sie von den Normalisierungsregeln abweichen, sollten Sie besonders wachsam sein, wie Sie die Datenbankintegrität erzwingen. Wenn Sie redundante Informationen speichern, setzen Sie Trigger und andere Kontrollen ein, um sicherzustellen, dass die Informationen konsistent bleiben.