NoSQL innerhalb von SQL Server

Bei dieser Frage geht es nicht um den Unterschied zwischen SQL und NoSQL. Ich bin auf der Suche nach einer Begründung für etwas, das für mich im Moment wirklich keinen Sinn ergibt (möglicherweise aufgrund meines Unverständnisses oder meiner mangelnden Wertschätzung).

Wir haben ein neues Projekt mit MVC5, Entity Framework 6 Code First und SQL Server 2008 von Grund auf neu gestartet. Als der Architekt das Datenbankschema überprüfte, wurde angegeben, dass alle Fremdschlüssel und andere solche Einschränkungen entfernt werden sollten, da dies „Geschäftslogik“ und „Geschäftslogik“ ist sollte innerhalb der Business-Schicht des Anwendungscodes angewendet werden.

Meiner Meinung nach bilden Fremdschlüssel einen Teil der Daten- / Referenzintegrität und ahmen die Geschäftslogik nicht wirklich nach. Ich sehe Geschäftslogik eher als den Prozess und die Validierung, die steuern, was / wann / wie / warum Referenzen angewendet werden. Ich kann irgendwie verstehen, dass eindeutige Einschränkungen wohl Geschäftsprozesse sind, aber für mich ergänzt dies nur die Logik und ist Teil der Integrität.

Ein zweites Argument ist das Ziel eines NoSQL-Ansatzes für die Daten. Ich fand das wirklich ungewöhnlich und unorthodox: In Anbetracht der Verwendung von SQL-Server 2008, der Notwendigkeit der Berichterstellung, der nicht auf Terabyte skalierbaren Daten und der mangelnden Berücksichtigung von Technologien wie Mongo, Raven usw.

Hat jemand schon einmal ein solches Szenario erlebt? Warum sollte jemand einen NoSQL-Ansatz in einem SQL Server anwenden, der für referenzielle Daten konzipiert ist und keine Fremdschlüssel möchte?

sql sql-server nosql

— Andy Clark
quelle

Sprechen Sie mit Ihrem Systemarchitekten über die Gründe für seinen Rat. Entweder hat er einen sehr guten Grund, der auf Ihren speziellen Fall zutrifft (ein Grund, den wir nicht unbedingt erraten können, ohne genau zu wissen, woraus Ihre App besteht), oder er ist einfach inkompetent.

— Arseni Mourzenko

Ich habe viele Datenbanken auf ähnliche Weise implementiert gesehen: keine FKs, keine CHECK-Einschränkungen - jedes Mal waren dies Datenbanken, die von unerfahrenen Programmierern entwickelt wurden, die nichts über Datenbankarchitektur, referenzielle Integrität usw. wussten. Es ist jedoch wichtig, dass Sie mit ihnen darüber diskutieren Ihr Kollege, anstatt einfach anzunehmen, dass er inkompetent ist.

— Arseni Mourzenko

Ich bin etwas verwirrt. Sie erwähnen die Verwendung des Entity-Frameworks (Code zuerst). Bedeutet dies nicht, dass Sie Objekte (im Sinne von C #) erstellen und dann das Entity-Framework die Erstellung der Datenbankäquivalente durchführen lassen. In diesem Fall wird versucht, FKs usw. hinzuzufügen / zu entfernen Eine Übung zum Überlisten von Entity Framework (ähnlich wie Mark Twains Zitat über den Versuch, einem Schwein das Singen beizubringen?)

— Foon,

Es gibt zu viele Leute, die sich selbst als "Architekten" bezeichnen, aber eigentlich keine Erfahrung im Codieren oder Warten größerer Systeme haben.

— Doc Brown

Relevant: thedailywtf.com/articles/The-Mythical-Business-Layer . "Wenn Sie darüber nachdenken, ist praktisch jede Codezeile in einer Softwareanwendung Geschäftslogik." Dies erstreckt sich auf die Datenbank. "Aber es ist genauso wichtig - wenn nicht noch wichtiger - zu bedenken, dass fast der gesamte Code einer Anwendung Geschäftslogik sein wird. Es gibt bereits genügend Tools; Ihre Anwendung benötigt keine generische Ebene " (Hervorhebung von mir). Die Person, die dies empfiehlt, versucht wahrscheinlich, die Datenbank in eine solche generische Ebene umzuwandeln. Kurz gesagt, sie setzen höchstwahrscheinlich Schlagworte über die Realität.

— jpmc26

Antworten:

Bei der Überprüfung des Datenbankschemas gab er an, dass alle Fremdschlüssel und andere solche Einschränkungen entfernt werden sollten, da dies Geschäftslogik ist und innerhalb der Geschäftsschicht angewendet werden sollte.

Dann ist er ein Idiot, und ein Auszug aus Ihrer Codebasis wird wahrscheinlich eines Tages auf The Daily WTF landen. Sie haben absolut Recht, dass sein Ansatz keinen Sinn ergibt, und ehrlich gesagt auch nicht seine Erklärung.

Erklären Sie ihm, dass referenzielle Integritätsbedingungen keine "Geschäftslogik" sind. Sie sind ein Korrektheitsstandard mit einer eigenen eingebauten Verifikation. In der Geschäftslogik geht es darum, was Sie mit den Daten tun. Bei der Integrität geht es darum, sicherzustellen, dass die Daten selbst nicht beschädigt sind. Und wenn das nicht funktioniert ... ist er verantwortlich. Sie können entweder seinem Plan folgen und versuchen, den Schaden etwas abzumildern, oder nach einem besseren Arbeitsplatz suchen. (Oder beides.)

— Mason Wheeler
quelle

Ich hatte eine etwas diplomatischere Antwort, die versuchte, einen (vernünftigen) Grund zu finden, warum der Architekt dies tun könnte. Nach nüchterner Überlegung komme ich stattdessen mit dieser Antwort an Bord.

— Blrfl

Whoa whoa, schlechte Architekturversuche sind ein Grund, woanders zu arbeiten? Verdammt, ich hätte nirgendwo weiterarbeiten können, wenn ich diese Einstellung gehabt hätte.

— Kzqai

@ Kzqai da ist auch der Architekt, der die Architektur grundlegend missversteht. Das hört sich an wie die Direktive 595, und wenn jemand mich zwingen wollte, mit Hämmern Schrauben in ein Stück Holz zu stecken, werde ich jemanden finden, der mich nicht zwingt, die Werkzeuge zu missbrauchen, um etwas zu bauen.

Die referenzielle Integrität ist ein zentrales Thema in der Datenbanktheorie, ganz zu schweigen von allen Datenbanken, die sie in der realen Welt unterstützen. Offensichtlich hat Andys Kollege in seiner Analyse Recht, der Rest der akademischen und beruflichen Welt liegt zu 100% falsch. Bonuspunkte für die Erwähnung von The Daily WTF .

@AndyClark Du solltest darüber aufhören. Grund dafür ist, dass es sich um eine nukleare Zeitbombe im Kern Ihres Unternehmens handelt. Es ist nur eine Frage der Zeit, wann die Fäkalien auf das Beatmungsgerät einwirken. In diesem Fall haben Sie das Glück, eine 72-Stunden-Schicht zu absolvieren. Im schlimmsten Fall würden Sie sich nach einem Job umsehen. Besser, Sie suchen einen Job, wenn Sie ein Einkommen haben.

— Kunst

Ich habe noch keinen Grund, einen Fremdschlüssel zu erstellen

- Joel Spolsky

Abgesehen von pauschalen Aussagen sollte anerkannt werden, dass es legitime und starke Gründe gibt, sich dafür zu entscheiden, keine Eindeutigkeits- oder Fremdschlüsseleinschränkungen zu verwenden. Die meisten gehen so etwas:

Performance. Integritätsprüfungen mit atomaren Transaktionen sind nicht kostenlos. Häufig ist die Skalierbarkeit der Datenbank in Ihrer Architektur am schwierigsten. Vielleicht überprüfen Sie bereits Ihre Anwendungslogik und möchten lieber keinen zweiten Leistungseinbruch verzeichnen.
Mangel an Notwendigkeit. Vielleicht sind Ihre Daten schmutzig und Sie sind damit einverstanden. Dies hängt sehr davon ab, was Sie tun.

Siehe auch Was ist los mit Fremdschlüsseln?

Aber diese stimmen nicht mit den Gründen in Ihrer Frage überein.

Dies ist Geschäftslogik und sollte innerhalb der Geschäftsschicht angewendet werden.

Dieser Grund ist ein bisschen seltsam. Eindeutigkeit und andere Integritätsbeschränkungen sind in hohem Maße die Domäne einer ACID-Datenbank. Ihr Anwendungscode kann die Atomaritäts- und Integritätsgarantien von SQLServer nicht erreichen. Wenn Sie starke Datenintegrität benötigen, wäre es dumm, die Datenbank zu ignorieren.

Ein zweites Argument ist, dass sie den NoSQL-Ansatz für ihre Datenspeicherung übernehmen möchten und daher keine solchen Einschränkungen wünschen.

Der zweite Grund ist nicht wirklich ein Grund; Es ist eine Schlussfolgerung. Zwar sind Einschränkungen ein Kompromiss zwischen Korrektheit und Leistung, und NoSQL-Datenbanken tendieren zu letzterer.

Vielleicht hat Ihr Systemarchitekt diese legitimen Gründe im Sinn, und Sie haben es falsch verstanden. Oder vielleicht ist er ein quälender Idiot.

In jedem Fall gibt es gültige (wenn auch nicht universelle) Gründe, auf die Verwendung von Eindeutigkeits- und Fremdschlüsselbeschränkungen zu verzichten.

PS Wenn Sie zu dem Schluss kommen, dass Sie keine Fremdschlüssel möchten, können Sie trotzdem eine relationale Datenbank verwenden. Als Verallgemeinerung sind relationale Datenbanken ausgereifter als ihre NoSQL-Gegenstücke. Als einzelner Knoten können sie sogar schneller sein , und eine NoSQL-Abstraktion kann darauf aufgebaut werden .

— Paul Draper
quelle

Ich wage zu sagen, Joel ist kein Idiot, aber eine witzige Antwort in einem Podcast, ohne jede Erklärung, ist meiner Meinung nach noch weniger wert als eine Aussage eines Idioten.

— Martin Ba

Joel ist ein Spreadsheet-Typ, kein Datenbank-Typ, daher ist seine Unkenntnis der relationalen Datenbank-Standardpraktiken, glaube ich, nicht überraschend ... Kein Vergehen, Joel. :-)

— Eric King

Joels aktuelles Zitat in Bezug auf den Kontext sind Technologien wie LINQ, die Anlass geben, sich mit der Einrichtung eines Fremdschlüssels zu beschäftigen. Joel ist kein Datenbankadministrator, und nachdem er seinen Blog durchsucht und lange gelesen hat, kann ich nichts von ihm finden, das über das Thema spricht oder Ratschläge zur Optimierung von Datenbanken, zum Entwerfen von Datenmodellen usw. gibt. Joel ist großartig , aber er ist jetzt noch nie - oder behauptet zu sein! - ein Experte auf dem Gebiet der Datenbanken oder Datenmodellierung. Es ist, als würde man Einstein über Zinseszins oder Sandwiches zitieren. (XKCD-Referenz, bitte.) :)

— BrianH

Joel Spolsky ist bekannt für seine kontroversen Meinungen. Siehe FogBugz ist in einer proprietären Sprache geschrieben . Die Abhängigkeitsinjektion ist zu kompliziert (übrigens war dies die umstrittenste Antwort auf Stackoverflow, bevor sie geschlossen wurde) . XML-Datenbanken sind langsam . etc.

— BlueRaja - Danny Pflughoeft

@BlueRaja: Umm ... XML-Datenbanken sind langsam, insbesondere im Vergleich zu relationalen Datenbanken. Seit wann ist das umstritten oder eine Meinung?

— Mason Wheeler