Wie Sie die redundanten Felder der Datenbank sinnvoll nutzen

Privot ist die Zwischentabelle von Viele-zu-viele-Beziehungen. Das PT5-Framework ruft Pivot automatisch auf.

Wir müssen es verstecken, weil wir Privot nicht brauchen und Privot nicht in unserem Modell selbst ist, es sind Zwischendaten

Zusätzlich zu den redundanten Feldern verfügen wir über eine Tabelle zur Erfassung von Bildern und eine weitere Tabelle zur Erfassung von Produkten.

Wir können die URL des Produktbildes in das Bild einfügen

Geben Sie gleichzeitig die Bild-ID und die Bild-URL in das Produkt ein

Diese beiden Felder werden wiederholt, was Datenredundanz darstellt. Wir entwerfen die Datenbank so, dass redundante Informationen vermieden werden. Warum also verwenden wir Redundanz?

Dies dient hauptsächlich Überlegungen zur Abfrageleistung.

Wir haben hier Datenredundanz vorgenommen, sodass wir die Anzahl der Abfragen an die Bildtabelle reduzieren und die Abfrage beschleunigen können!

Es wird jedoch empfohlen, die Datenredundanz nicht übermäßig zu nutzen, da es durch Datenredundanz schwierig wird, die Datenintegrität und -konsistenz aufrechtzuerhalten. Es gibt zwei Orte, an denen dieselben Informationen aufgezeichnet werden, aber wenn wir Daten schreiben, müssen wir sie an zwei Orte schreiben. Das größte Problem ist das Löschen und Aktualisieren. Wenn sich beim Aktualisieren das IMG an einer Stelle ändert, müssen Sie beide ändern. Andernfalls kommt es zu Dateninkonsistenzen. Allerdings wird Datenredundanz immer noch recht häufig verwendet.

Bei der Web-Entwicklung kann neben der Beherrschung einiger notwendiger Datenbankoptimierungstechniken auch die Verwendung redundanter Felder zum richtigen Zeitpunkt mit halbem Aufwand das doppelte Ergebnis erzielen. Im folgenden Beispiel gibt es beispielsweise mehrere Tabellen, die auf diese Weise gestaltet sind.

• Benutzertabelle [Benutzer]: ID, Benutzername
• Projekttabelle [Projekt]: ID, Projektname, Benutzer-ID
• Versionstabelle [Version]: ID, Versionsname, Projekt-ID
• Kategorietabelle [Kategorie]: ID, Kategoriename, Versions-ID
• Inhaltstabelle [Inhalt]: ID, Text, Kategorie-ID

Das ist alles. Es sieht gut aus, ohne redundante Felder. Es entspricht außerdem den drei Hauptparadigmen des Datenbankdesigns.

Stellen wir zunächst eine Frage, nennen wir sie Frage X.

Frage X: Wenn Sie die Inhaltsverzeichnisliste unter einer bestimmten Version abfragen möchten, sollte das SQL folgendermaßen geschrieben werden:

Wählen Sie c.* aus Inhalt c, Kategorie t, wobei c.category_id=t.id und t.version_id=?

Es scheint kein Problem zu sein. Wie kann diese Abfrage optimiert werden? Diese Frage werden wir zuletzt diskutieren. Kehren wir zum obigen Tabellenentwurf zurück, falls ein solches Problem vorliegt. Ich möchte beispielsweise überprüfen, ob Inhalt A dem Benutzer U gehört. Was muss ich tun?

• Suche nach Kategorie B, zu der Inhalt A gehört
• Abfrageversion C der Kategorie B
• Abfrage Projekt D, zu dem Version C gehört
• Abfrage, ob Element D dem Benutzer U gehört, und damit Feststellung, ob Inhalt A dem Benutzer U gehört

Das ist ein äußerst schlechtes Verhalten, nicht wahr? An diesem Punkt sollte Ihnen die Schwäche dieses Tabellendesigns bewusst geworden sein. Was sollen wir also tun?

Redundante Felder! Ja, wir müssen der Tabelle redundante Felder hinzufügen. Was würde passieren, wenn wir zu jeder der oben genannten Tabellen (außer der Benutzertabelle) ein user_id-Feld hinzufügen würden?

Erstens können Sie sicher sein, dass sich der Wert des Felds „user_id“ in den einzelnen Tabellen nicht ändert. Daher muss der Wert dieses Felds nach der Festlegung nicht mehr geändert werden.

Dann kehren wir zur obigen Frage zurück: Abfrage, ob Inhalt A dem Benutzer U gehört. Der aktuelle Ansatz ist folgender:

Überprüfen Sie, ob die Benutzer-ID von Inhalt A die ID von Benutzer U ist

Nur ein Schritt! So einfach und grob, oder? Ziemlich erfrischend, oder?

Durch einfaches Hinzufügen des redundanten Felds user_id kann der Codierungsaufwand erheblich reduziert und die Effizienz der Datenbankabfrage um das N-fache erhöht werden. Außerdem muss dieses Feld nur einmal gepflegt werden!

Nachdem Sie nun die Leistungsfähigkeit redundanter Felder kennen, kehren wir zu Frage X zurück. Wie kann diese Geschäftslogik optimiert werden?

Der richtige Ansatz wäre: Fügen Sie in der Inhaltstabelle ein zusätzliches Feld „version_id“ hinzu. Es ist sicher, dass dieses Feld dem Feld „user_id“ ähnelt und nur einmal gepflegt werden muss.

Anschließend wird das SQL für Frage X wie folgt geändert:

Wählen Sie c.* aus Inhalt c, wobei c.version_id=?

Ziemlich einfaches SQL!

Das Obige zeigt, dass manchmal eine entsprechende Datenbankredundanz eine gute Wahl ist.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM. Wenn Sie mehr darüber erfahren möchten, schauen Sie sich bitte die folgenden Links an