Explo Datenbank-Design-Tipps

Einer der wichtigsten Aspekte eines jeden Anwendungsentwicklungsprojekt ist die Datenbank-Design. Und so, ohne weitere Umschweife, hier sind einige Tipps für eine gute Datenbanken zu entwerfen.

Verwenden Sie die richtige Anzahl von Tabellen

Im Amadeus, der Kaiser von Deutschland kritisiert eine von Mozarts Werken als mit "zu viele Noten." Mozart antwortet entrüstet, dass er weder zu viele noch zu wenige Noten verwendet, aber die genaue Anzahl der Noten, die die Zusammensetzung erfordert.

So sollte es mit Datenbank-Design sein. Ihre Datenbank sollte so viele Tabellen haben, wie es die Anwendung erfordert - nicht mehr, nicht weniger. Es gibt keine "richtige" Anzahl von Tabellen für alle Datenbanken.

Unerfahrene Datenbank-Designer haben eine Tendenz, zu wenige Tabellen zu verwenden - manchmal eine ganze Datenbank-Wert von Informationen in einer einzigen Tabelle zu stopfen versucht. Im anderen Extrem sind Datenbanken, mit Dutzenden von Tabellen, die jeweils aus nur wenigen Feldern.

Vermeiden Sie Daten zu wiederholen

Eines der Grundprinzipien der relationalen Datenbank-Design ist es, Daten zu handhaben zu wiederholen, indem Sie sie in einer separaten Tabelle zu brechen. Zum Beispiel in den alten Tagen der Flat-File-Verarbeitung war es üblich, Rechnung Datensätze erstellen, die Raum für eine bestimmte Anzahl von Positionen hatte. So würde der Rechnungssatz haben Felder mit Namen wie Element1, Element2, Item3, und so weiter.

Schlecht!

Jedes Mal, wenn Sie sich die Nummerierung Feldnamen wie das zu finden, sollten Sie eine separate Tabelle erstellen. Im Falle der Rechnungssatz, sollten Sie eine separate Tabelle, die die Positionsdaten zu speichern, erstellen.

Vermeiden Sie redundante Daten

Wenn die Tabellen entwerfen, die Ihre Datenbank zu machen, versuchen Sie redundante Daten zu vermeiden, zu schaffen. Jedes Mal, wenn redundante Daten in eine Datenbank kriecht, stellt es die Wahrscheinlichkeit, dass die Daten beschädigt werden wird. Zum Beispiel: Angenommen, Sie Namen eines Kunden gespeichert werden in zwei verschiedenen Tabellen. Dann, wenn Sie den Namen in einer der Tabellen aktualisieren, aber nicht die andere, hat die Datenbank inkonsistent werden.

Die naheliegendste Art von redundanten Daten Fehler ist, ein Feld zu schaffen, die in zwei oder mehr Tabellen existiert. Aber es gibt auch subtilere Arten von redundanten Daten. Betrachten wir zum Beispiel ein Rechnung Tabelle, die eine enthält LineItemTotal Feld, das die Summe der darstellt, Gesamt Felder in jedem der Positionen der Rechnung. Technisch stellt dieses Feld redundante Daten- die Daten auch in der gespeichert wird Gesamt Felder jeder Position.

Egal, ob Sie sollten diese Art von Redundanz ermöglichen, sich auf die Anwendung abhängt. In vielen Fällen ist es besser, mit der Redundanz für die Bequemlichkeit setzen und die Effizienz der nicht den Gesamt jedes Mal auf die Daten zugegriffen wird neu berechnet werden müssen. Aber es ist immer eine Überlegung wert, ob die zusätzliche Bequemlichkeit wert ist das Risiko, die Daten beschädigt.

Verwenden Sie eine Namenskonvention

Um Verwirrung zu vermeiden, eine Namenskonvention für Ihre Datenbankobjekte auswählen und dabei zu bleiben. Auf diese Weise Ihre Datenbank-Tabellen, Spalten, Einschränkungen und andere Aufgaben werden in einer konsistenten und vorhersagbaren Weise benannt werden. (Man denke nur an die Einsparungen auf Aspirin.)

Sie können bis St. Swithen Tag über das, was die Namenskonventionen von nun argumentieren sollte Sein. Das spielt keine Rolle, so viel. Was tut, ist Sache, dass Sie eine Konvention zu machen - und ihm folgen.

vermeiden Sie nulls

Zulassen von NULL-Werte in Datenbanktabellen erschwert erheblich die Anwendungsprogrammierung die Tabellen für den Zugriff. Als Ergebnis vermeiden nulls von NULL Angabe nicht, wann immer Sie können. Verwenden Sie nulls selten, und nur, wenn Sie wirklich brauchen.

Nulls sind oft ohnehin missbraucht. Der richtige Einsatz von null ist für einen Wert, der ist unknown- nicht für eine leere oder leere Wert. Betrachten wir zum Beispiel eine typische Adressdatensatz, der zwei Adressleitungen ermöglicht, mit dem Namen Adresse 1 und Adresse 2. Die meisten Adressen haben nur eine Adresse, so dass die zweite Adresszeile ist leer. Der Wert dieser zweite Adresszeile ist in der Tat bekannt - es ist leer. Das ist nicht dasselbe wie null. Null würde bedeuten, dass die Adresse eine zweite Adresse kann linien- wir nicht nur wissen, was es ist.

Auch für Spalten, die für NULL-Werte angemessen erscheinen mag, ist es meist bequemer, einfach den Wert der Spalte leer lassen für Werte, die nicht bekannt sind. Betrachten wir zum Beispiel ein Telefonnummer Säule in ein Kunde Tabelle. Es ist sicher davon ausgehen, dass alle Ihre Kunden Telefonnummern haben, so wäre es richtig für Telefonnummern null zu verwenden, die Sie nicht kennen. Doch von einem praktischen Standpunkt aus gesehen, es ist nur so einfach nulls für die Telefonnummer Spalte zur Untersagung, und lassen Sie die unbekannte Telefonnummern leer.

Vermeiden Geheimcodes

Vermeiden Sie Felder mit Namen wie Kundentyp, wobei der Wert des Feldes ist eine von mehreren Konstanten, die nicht an anderer Stelle in der Datenbank definiert sind, wie beispielsweise R für Verkauf oder W für Großhandel. Sie können nur diese beiden Arten von Kunden heute haben, aber die Anforderungen der Anwendung kann sich in Zukunft ändern, eine dritte Art des Kunden erfordert.

Eine Alternative wäre, eine separate Tabelle kundenTypCodes zu erstellen sie (Call CustomerTypes) Und dann eine Fremdschlüsseleinschränkung so den Wert des erstellen Kundentyp Spalte muss in der erscheinen CustomerTypes Tabelle.

Verwenden Sie Einschränkungen mit Bedacht

Einschränkungen können Sie Änderungen an der Datenbank zu verhindern, die die interne Konsistenz der Daten zu verletzen. Zum Beispiel können Sie eine Check-Einschränkung nur Daten validieren, die bestimmte Kriterien erfüllt. Zum Beispiel können Sie eine Check-Bedingung verwenden, um sicher den Wert eines Feldes machen benannt Preis größer als Null ist.

EIN Fremdschlüssel-Constraint setzt voraus, dass der Wert einer Spalte in einer Tabelle mit dem Wert übereinstimmen muss, die in einer anderen Tabelle existiert. Zum Beispiel, wenn Sie ein Lineitems Tabelle mit einer Spalte mit dem Namen Produkt ID, und Produkte auch Tabelle mit einer Spalte mit dem Namen Produkt ID, Sie könnten eine Fremdschlüsselbedingung verwenden, um sicherzustellen, dass die Produkt ID Wert für jede Zeile in der Lineitems Tabelle entspricht einer vorhandenen Zeile in der Produkte Tabelle.

Verwenden Sie löst bei Bedarf

EIN Auslöser ist ein Verfahren, aktualisiert oder abgerufen in, wenn bestimmte Daten in der Datenbank startet. Auslöser sind eine gute Möglichkeit, diese Datenbank Regeln zu erzwingen, die komplizierter als einfache Einschränkungen sind. Beispiel: Angenommen, ein Rechnung Tabelle enthält eine ItemCount Spalte, deren Wert ist die Anzahl der Einzelposten für die Rechnung. Eine Möglichkeit, den Wert dieser Spalte zu halten automatisch würde Trigger zu erstellen, die erhöhen ItemCount Spalte, wenn eine Position eingeführt wird, und verringern die ItemCount Spalte, wenn eine Position gelöscht wird. Manchmal ist die Automatisierung eine schöne Sache.

Verwenden Sie gespeicherte Prozeduren

Gespeicherte Prozeduren SQL-Prozeduren, die in der Datenbank und sind ein Teil davon sind versteckt. Es gibt mehrere Vorteile für gespeicherte Prozeduren anstelle von Codierung SQL in Ihre Anwendungen:

• Unter Verwendung von gespeicherten Prozeduren entfernt die Last der SQL-Programmierung von Ihrem Anwendungsprogrammierer. Stattdessen macht es die SQL der Datenbank einen Teil der Datenbank für den Zugriff selbst - keine Aufregung, kein Durcheinander. die Anwendungsprogramme zu tun haben, ist es, alle entsprechenden gespeicherten Prozeduren aufrufen, zum Auswählen, Einfügen, Aktualisieren oder Datenbankdaten zu löschen.
• Stored Procedures sind effizienter als eine Möglichkeit der Handhabung Transaktionen, da der Datenbankserver die gesamte Transaktion behandelt.
• Stored Procedures sind auch effizienter, da sie die Menge der Netzwerkverkehr zwischen dem Datenbank-Server und dem Web-Server zu reduzieren.
• Schließlich sind gespeicherte Prozeduren sicherer, weil sie das Risiko von SQL-Injection-Angriffe zu reduzieren.