Wenn Sie eine Datenbank zur Verwendung von MVCC (Multi-Version Concurrency Control) entwerfen, erstellen Sie Tabellen mit einem booleschen Feld wie "IsLatest" oder einer Ganzzahl "VersionId", und Sie nehmen keine Aktualisierungen vor, Sie fügen nur neue Datensätze ein Dinge ändern sich.
MVCC bietet Ihnen eine automatische Überwachung für Anwendungen, die eine detaillierte Historie benötigen, und entlastet die Datenbank in Bezug auf Update-Sperren. Die Nachteile sind, dass es Ihre Datengröße viel größer macht und verlangsamt, aufgrund der zusätzlichen Klausel, die notwendig ist, um die neueste Version zu erhalten. Es macht auch Fremdschlüssel komplizierter.
(Beachten Sie, dass ich nicht über die native MVCC-Unterstützung in RDBMS wie die Snapshot-Isolationsstufe von SQL Server spreche)
Dies wurde in anderen Beiträgen hier in Stack Overflow besprochen. [Todo - Links]
Ich frage mich, welche der vorherrschenden Entity / ORM-Frameworks (Linq bis Sql, ADO.NET EF, Hibernate usw.) diese Art von Design sauber unterstützen können? Dies ist eine wesentliche Änderung des typischen ActiveRecord-Entwurfsmusters. Daher bin ich mir nicht sicher, ob die Mehrzahl der Tools, die da draußen sind, jemandem helfen könnte, der sich dafür entscheidet, diese Route mit seinem Datenmodell zu gehen. Ich bin besonders daran interessiert, wie fremde Schlüssel gehandhabt werden, weil ich nicht einmal sicher bin, wie sie MVCC am besten modellieren können.
Ich könnte erwägen, die MVCC-Ebene rein in der DB zu implementieren, indem ich gespeicherte Prozeduren und Ansichten verwende, um meine Datenoperationen zu verarbeiten. Dann könnten Sie jedem ORM eine vernünftige API präsentieren, die in der Lage ist, zu und von gespeicherten Procs zu mappen, und Sie könnten die Datenbank mit den Datenintegritätsproblemen befassen (da es dafür ziemlich viel gebaut ist). Wenn Sie diesen Weg gehen, sollten Sie sich eine reinere Mapping-Lösung wie IBatis oder IBatis.net ansehen.
Ich habe eine Datenbank ähnlich entworfen (nur INSERTs - keine UPDATEs, keine DELETEs).
Fast alle meine SELECT-Abfragen waren gegen Ansichten nur der aktuellen Zeilen für jede Tabelle (höchste Revisionsnummer).
Die Ansichten sahen so aus ...
%Vor%Und meine Einfügungen (und Updates und Löschungen) wurden alle von gespeicherten Prozeduren behandelt (eine pro Tabelle).
Die gespeicherten Prozeduren sahen so aus ...
%Vor%Revisionsnummern wurden pro Transaktion im Visual Basic-Code behandelt ...
%Vor%Ich habe für jede Tabelle ein Objekt mit Konstruktoren, Instanzeigenschaften und Methoden, create-update-delete-Befehlen, einer Reihe von Finder-Funktionen und IComparable-Sortierfunktionen erstellt. Es war eine riesige Menge Code.
Eins-zu-eins-DB-Tabelle zu VB-Objekt ...
%Vor%Ein solches System behält alle früheren Versionen jeder Zeile bei, aber es kann sehr mühsam sein, es zu verwalten.
PROS:
CONS:
SCHLUSSFOLGERUNG:
Ich bin gespannt, ob das Microsoft Entity Framework solche Datenbankdesigns gut beherrscht.
Jeff und der Rest des Stack Overflow-Teams mussten während der Entwicklung von Stack Overflow ähnliche Probleme haben: Frühere Versionen der bearbeiteten Fragen und Antworten sind gespeichert und abrufbar.
Ich glaube, Jeff hat erklärt, dass sein Team Linq zu SQL und MS SQL Server benutzt hat.
Ich frage mich, wie sie diese Probleme behandelt haben.
Nach meinem besten Wissen werden ORM-Frameworks den CRUD-Code für Sie generieren wollen, also müssten sie explizit entworfen werden, um eine MVCC-Option zu implementieren; Ich kenne keine, die so out-of-the-box tun.
Aus Sicht des Entity-Frameworks implementiert CSLA überhaupt keine Persistenz - es definiert lediglich eine "Datenadapter" -Schnittstelle, mit der Sie die von Ihnen benötigte Persistenz implementieren. So könnten Sie Code-Generierungsschablonen (CodeSmith, etc.) einrichten, um automatisch CRUD-Logik für Ihre CSLA-Entitäten zu generieren, die mit einer MVCC-Datenbankarchitektur einhergehen.
Dieser Ansatz würde mit jedem Entitätsrahmen funktionieren, höchstwahrscheinlich nicht nur mit CSLA, aber es wäre eine sehr "saubere" Implementierung in CSLA.
Sieh dir das Envers-Projekt an - funktioniert gut mit JPA / Hibernate-Anwendungen und macht das im Grunde für dich - verfolgt verschiedene Versionen jeder Entity in einer anderen Tabelle und gibt dir SVN-ähnliche Möglichkeiten ("Gib die Version der Person an, die benutzt wird 2008-11-05 ... ")
/ Jens
Ich dachte immer, dass Sie einen db-Trigger für update und delete verwenden würden, um diese Zeilen in eine TableName_Audit-Tabelle zu verschieben.
Das würde mit ORMs funktionieren, Ihnen Ihre Historie geben und die ausgewählte Performance in dieser Tabelle nicht dezimieren. Ist das eine gute Idee oder fehlt mir etwas?
Was wir tun, ist nur ein normaler ORM (Ruhezustand) und behandeln Sie die MVCC mit Ansichten + anstelle von Triggern.
Also, es gibt eine v_emp-Ansicht, die nur wie eine normale Tabelle aussieht, die Sie einfügen und darin gut aktualisieren können. Wenn Sie das tun, behandeln die Trigger tatsächlich die richtigen Daten in die Basistabelle.
>Nicht .. Ich hasse diese Methode :) Ich würde mit einer gespeicherten Prozedur-API gehen, wie von Tim vorgeschlagen.
Tags und Links entity-framework database orm