Wäre es jemals sinnvoll, wenn die Anwendung die Datenbankintegrität erzwingt, anstatt über Fremdschlüssel zu verfügen, Einschränkungen zu überprüfen usw.?
Inwieweit ist eine Leistungsverbesserung zu erwarten, wenn die Datenbankintegrität nicht durch interne Datenbanktools erzwungen wird?
Antworten:
Um ehrlich zu sein, werden Sie nicht nur kaum Leistungseinbußen durch Fremdschlüsseleinschränkungen in der Datenbank feststellen, sondern auch Leistungsverbesserungen feststellen. Das SQL Server-Abfrageoptimierungsprogramm basiert auf dem Konzept von Primär- und Fremdschlüsseln sowie anderen Arten von Dateneinschränkungen. Wenn diese vorhanden und erzwungen sind, kann das Optimierungsprogramm sie nutzen, um eine bessere Leistung zu erzielen. Hier ist ein Blog-Beitrag mit einem einfachen Beispiel , das es in Aktion zeigt.
Wenn Sie sich in einem Randfall befinden, in dem tatsächlich mehr Einfügungen als Lesevorgänge vorliegen (und Aktualisierungen und Löschvorgänge Lesevorgänge erfordern, sodass sie normalerweise zur Lesezahl hinzugefügt werden), ist es möglicherweise sinnvoll, Einschränkungen für die Leistung aus den Daten zu entfernen . Da die überwiegende Mehrheit der Datenbanken jedoch lesebezogen ist, wird die Leistung nicht verbessert, sondern geopfert.
In keinem Fall wird erwähnt, dass die Datenintegrität in der Datenbank besser gehandhabt wird, da Sie sie nur einmal erstellen müssen, wenn Sie die gesamte Arbeit im Code erledigen, und dies möglicherweise mehrmals für mehrere Apps tun müssen (es sei denn, Sie entwerfen Ihre Datenzugriffsebene sorgfältig und erfordern, dass jede App auf die Datenbank zugreift, um dieselbe Ebene zu durchlaufen).
Wenn Sie ein relationales Datenbanksystem verwenden, sage ich, warum sollten Sie es nicht wirklich verwenden? Wenn Sie keine relationalen Daten benötigen, entscheiden Sie sich für Hadoop oder etwas anderes.
Viele Anwendungsentwickler denken das auch.
Wenn Sie versucht sind, die Datenintegrität an den Anwendungscode zu delegieren, denken Sie: "Jeder Programmierer und jede Anwendung, die von jetzt an bis zum Ende der Zeit auf diese Datenbank zugreift, muss es jedes Mal perfekt machen."
Was sind die Chancen?
Selbst wenn es einen Leistungsgewinn gibt, ist dieser im Vergleich zur Wiederherstellung der referenziellen Integrität und der allgemeinen Datenintegrität vernachlässigbar.
Vorbei sind die Zeiten, in denen eine Datenbank ein dummer Datenspeicher ist. Nutzen Sie die Leistung, die RDBMS bietet.
Leistungszuwächse sind nicht alles, besonders in einem so kleinen Maßstab. Wenn Sie jedoch feststellen, dass Ihre Anwendung eine vermeintliche Fremdschlüsselbeziehung erzwingen soll und dies kein Primärschlüssel in der Referenzierungstabelle ist, interessiert Sie der Leistungsgewinn nur wenig (sofern vorhanden) Ich spreche nicht über die Einzelheiten davon.
Es ist gängige Praxis, Einschränkungen (Fremdschlüssel, CHECK usw.) und Indizes zu löschen, wenn Sie ausreichend Daten laden, und die Einschränkungen und Indizes anschließend erneut zu aktivieren / implementieren. Diese Validierung kostet Zeit. Dies setzt voraus, dass Sie keine datenbankspezifische Massenladesyntax verwenden können (einschließlich Minimierung der Protokollierung).
Es ist unmöglich zu sagen, wie viel Leistungssteigerung zu erwarten ist - jede Situation ist einzigartig (Datentypen, Design usw.). Der einzige Weg, um wirklich zu wissen, ist zu testen.
Es gibt einige Male, in denen Einschränkungen im Weg stehen:
Wenn Sie Single Table Inheritance (STI) verwenden müssen. Stellen Sie sich vor, Sie verkaufen sowohl an Einzelpersonen als auch an Organisationen. Sie benötigen eine einzelne "Party" -Tabelle, deren Zeile entweder eine Einzelperson oder eine Organisation ist. STI bedeutet, dass Sie einige nullfähige Felder benötigen, die nicht null sein dürfen. Die Vererbung von Klassentabellen behebt dieses Problem, was jedoch für einige ORMs schwieriger ist. Rubys ActiveRecord unterstützt beispielsweise nur STI.
Wenn Sie Entwurfsversionen einer Entität unterstützen müssen, ist dies möglicherweise nicht vollständig gültig. Sie könnten einen Entwurf als json speichern, aber dann ist es schwieriger, denselben Bezeichner auf dem Client wiederzuverwenden. Stellen Sie sich vor, er wurde mit id = 5 gespeichert, so bearbeitet, dass er ungültig ist, und als draftid = 99 automatisch gespeichert. In diesem Fall müssen wahrscheinlich alle Ihre Felder nullfähig sein.