Wir haben eine ziemlich antiquierte Datenbank, die eine große Anzahl von Personen zusammen mit einer Reihe von Errungenschaften enthält, die sie abgeschlossen haben. Es wurde in der Vergangenheit wenig unternommen, um doppelte Daten zu vermeiden, so dass wir in einer Situation enden, in der unsere Daten ziemlich schmutzig sind. Eine stark vereinfachte Version davon finden Sie hier .
Wir gestalten jetzt das Schema und die Benutzeroberfläche neu. Wir werden dem Benutzer ein Werkzeug zur Verfügung stellen, um seine Personen zusammenzuführen. In dem bereitgestellten Beispiel sind Dave und David eindeutig die gleiche Person und haben insgesamt 4 Erfolge erzielt.
Da die Benutzer Fehler machen und es wesentlich mehr Tabellen als im Beispiel gibt, suche ich nach einem Schemadesign, das das einfache Zusammenführen von Daten erleichtert, und insbesondere das Unvereinigen von Daten, wenn (wenn!) der Benutzer macht unweigerlich einen Fehler.
Verknüpfte Listen in irgendeiner Form scheinen eine Lösung zu sein, sind aber für diesen Anwendungsfall nicht gerade effizient. Gibt es andere Konzepte, die sich für diese Situation eignen? Irgendwelche spezifischen Entwurfsmuster, die angebracht sein könnten?
Bearbeiten : Da SQLFiddle heute ziemlich flockig ist, ist hier die create / insert / select sql, die auf sqlfiddle:
war %Vor%Bearbeiten 2: Gerade gefunden sehr ähnliche Frage , hoffend in 4 Jahren könnte es auch andere Lösungen geben.
Hier ist eine Taktik, die Sie verwenden könnten.
Erstellen Sie zuerst eine neue Tabelle, jetzt nennen Sie sie "Individual_v2", mit genau denselben Spalten wie die Originaltabelle Individual. (Im Idealfall ersetzen Sie Individual durch diese Tabelle. Realistischerweise können Personen Daten noch in Individual eingeben, und Sie müssen die Daten "bereinigen", indem Sie sie in Individual_v2 verschieben oder zusammenführen.) Konfigurieren Sie diese Tabelle mit Links zu Achievement. (Im Moment nehme ich an, dass Leistung sauber ist.)
Erstellen Sie dann eine "Mapping" -Tabelle wie folgt:
%Vor%Die Spalten "Created" werden verwendet, um zu bestimmen, wann und von wem (oder wie) das Mapping erstellt wurde.
Die Spalten "Genehmigt" werden verwendet, um zu bestimmen, ob die Daten in die neuen Tabellen migriert wurden.
Für jedes "alte" Element bestimmen Sie, wo es in der "neuen" Tabelle abbilden könnte; Wenn es keinem vorhandenen Objekt zugeordnet ist, erstellen Sie in der neuen Tabelle ein neues Element.
Fügen Sie dann einen Eintrag in der Zuordnungstabelle hinzu. Wenn ein neuer Artikel erstellt wurde, markieren Sie ihn als genehmigt. wenn das Vertrauen hoch ist, markieren Sie es als genehmigt; Andernfalls lassen Sie es "nicht genehmigt" und warten auf eine Überprüfung. Zu gegebener Zeit wird ein Prüfer die Dinge überprüfen und das Mapping genehmigen, das Mapping auf ein anderes existierendes neues Element ändern oder ein anderes neues Element erstellen und ihm zuordnen.
Nach der Fertigstellung wird die "echte" Arbeit an der neuen Tabelle ausgeführt. Die alte Tabelle und die Mapping-Tabelle können verwendet werden, um zu ermitteln, woher die neuen Daten stammen, und um Mappings rückgängig zu machen / zu ändern.
Es gibt eine Menge unbeantworteter Implementierungs- und Supportprobleme hier, und insgesamt scheint es peinlich zu sein. Langfristig, nachdem Sie das Problem der doppelten Daten gelöst haben, können Sie die alte (und die Zuordnung) Tabelle löschen, aber bis dahin haben Sie ein pingeliges System.
Zusätze
Ich rede hier ein bisschen durch die Dinge, ohne eine ausführliche Analyse zu machen. Das System, von dem ich denke, dass es beschrieben wird, wird sehr wählerisch und konzeptionell komplex sein, selbst wenn die Tabellen relativ einfach sind und die letzten Details außerhalb des Rahmens einer SO-Frage liegen. Viel hängt auch davon ab, was die allgemeinen Ziele des Systems und seine Neugestaltung sind. Ich werde hier einige Annahmen machen:
Das "existierende" System bleibt bestehen
Personen (und ihre Auszeichnungen), die so eingegeben wurden, müssen sofort verfügbar sein, wie sie es immer waren.
Duplikate werden weiterhin eingegeben. wenn, wann und wie machbar, sollen sie mit bereits existierenden Einträgen "konsolidiert" werden
Auf diese Weise würde das System wie folgt funktionieren:
Es gibt eine separate Relationstabelle zwischen den Individuen_v2 und Achievement (Individual_Achievement_v2 für den Moment, obwohl es einen besseren Namen geben muss).
Die Daten in den "v2" -Tabellen sind korrekt, gut und richtig. Die "v1" -Tabellen sind Staging-, Protokoll- und Protokolldaten.
Bereiten Sie eine erste Version vor, in der alle Einträge in den v1-Tabellen in den v2-Tabellen konfiguriert sind. Wenn Zeilen während dieses Schritts konsolidiert werden können, umso besser. Alles wird in der "Map" -Tabelle protokolliert, damit sie sauber zurückgelegt und bei Bedarf neu erstellt werden können.
Ab dieser Version werden neue Daten in die v1-Tabellen eingegeben und gleichzeitig / sofort auch in die v2-Tabellen eingegeben. Wenn eine Zuordnung zu einem vorhandenen Element vorgenommen werden kann, tun Sie dies, andernfalls erstellen Sie einen neuen Eintrag in den Tabellen v2. Protokollieren Sie die Aktivität immer in der Tabelle "map".
In Zukunft werden alle "Live" -Abfragen auf die v2-Tabellen angewendet. Die v1 Tabellen sind (wieder) History, Log, Audit Trail. Einmal gefüllt, werden sie nie geändert, während die v2-Tabellen (einschließlich der Mapping-Tabelle) können und werden.
Wie vom Unternehmen festgelegt, werden regelmäßige Überprüfungen / Überprüfungen an den Daten durchgeführt, um nach doppelten Einträgen zu suchen und diese zu korrigieren, sowie nach "ungültigen Duplikaten" (falsche Zuordnungen). Dies ist der Fall, wenn Sie die Rollback- / Wiederherstellungsarbeit ausführen, wie sie in den Tabellen mapping und v1 verfolgt wird.
Sie möchten vielleicht einige zusätzliche Protokolltabellen, um Dinge wie "alle Daten, die bis xx / xx / xxxx eingegeben wurden, gültig zu sein, die seither eingegebenen Daten müssen überprüft werden" zu verfolgen. Ich bin mir sicher, dass es noch andere Probleme und Feinheiten geben wird - sie tun es immer ...
Tags und Links merge design-patterns database-schema database-design