2011-01-12 9 views
0

Ich habe eine Datenbankstruktur mit zwei Eins-zu-viele-Beziehungen. Ich habe eine Website, die viele Themen hat, von denen jedes viele Fragen hat. Dies führt zu drei Datenbanktabellen, eine für jeden dieser Datentypen.Verschieben von Daten aus Staging-Tabellen in Live-Tabellen unter Beibehaltung der 1: n-Beziehung

Was ich gerade mache, ist die Implementierung eines Staging-Bereichs - irgendwo, wo ich Änderungen an diesen Websites vornehmen kann, ohne die Live-Site zu beeinträchtigen. Also habe ich die Tabellenstruktur dupliziert, um die Duplikate zu bearbeiten und Änderungen an der Live-Version vorzunehmen, wenn die Änderungen fertig sind. Ich möchte diesen Push in einer gespeicherten Prozedur machen, aber ich kann nicht herausfinden, wie man die Beziehung zwischen den Subjekten und ihren Fragen aufrechterhält.

Die Website verfügt über andere Identifikationsmerkmale als ihre ID, sodass es einfach ist, die Live-Version der Site zu finden, ihre Informationen zu aktualisieren und sogar die Themen dieser Website von den Staging-Tabellen auf die Live-Tabellen zu übertragen. Hier

ist einig Pseudo-Code für das, was mein Plan ist für die Push-:

-- pass in the ID of the staging website 
-- get the ID of the live website 
-- update live website data from staging website data 
    -- this is a strict update - if there is a staging version, there will necessarily be a live version 
-- delete all live subjects 
-- delete all live questions 
-- copy subjects from staging to live 
-- copy questions from staging to live 

Beachten Sie, dass Themen und Fragen hinzugefügt oder entfernt werden können, zusätzlich zu (so bearbeitet wird, zu löschen und wieder einfügen scheint den besten Kurs Handlungs).

Ich konnte tatsächlich Code für die meisten dieser schreiben, wie es relativ einfach ist. Aber es war ein Problem herauszufinden, wie man die Beziehung zwischen den Subjekten und den Fragen aufrechterhält. Wenn ich dies in einer serverseitigen Skriptsprache zu tun, würde ich so etwas tun (auch hier Pseudo-Code):

for each subject 
    copy information from staging subject to live subject 
    get id of new live subject 
    for each question in this subject 
     copy information from staging to live, setting subject ID to new live ID 

Wie gesagt, würde ich dies gerne alle Verfahren in derselben gespeichert halten. Wenn das nicht möglich ist, werde ich natürlich die obige Version wählen, aber aus Effizienzgründen möchte ich lieber nicht mehrere Datenbanktreffer haben.

Antwort

1

Sie müssen für jede Zeile keine neue Identität erstellen. Sie können Ihre Identitäten aus der Bereitstellung wiederverwenden.

Angenommen, Sie haben verknüpfte Server einrichten, können Sie die

SET IDENTITY_INSERT MYTABLENAME ON 

INSERT INTO MyTableName (IdenityColumn, Col1, Col2, Col3) 
SELECT StagingIdentityColumn, StagingCol1, StagingCol2, StagingCol3 
FROM StagingServer.StagingDatabase.DBO.MyTableName 

SET IDENTITY_INSERT MyTableName OFF 

Natürlich folgende tun, jetzt müssen Sie in der richtigen Reihenfolge eingefügt, so dass Sie referentielle Integrität intakt zu halten.

+0

Interessant. Dies ist definitiv eine Möglichkeit, aber öffnet das nicht die Türen für doppelte Identitäten? Außerdem bin ich mit der Beziehung zwischen der Einfügereihenfolge und der referenziellen Integrität nicht vertraut. Beziehen Sie sich darauf, Themen vor Fragen einzufügen, oder ist etwas Komplizierteres dabei? –

+0

Nun, solange Sie alle Identitäten ausschließen, die derzeit in beiden Systemen verwendet werden, und von nun an nur die neuen Daten vom Staging in die Produktion erhalten, sollten Sie keine Duplikate mehr haben. Hier erfahren Sie, wie Sie den aktuellen Wert der Identität zurücksetzen können. http://msdn.microsoft.com/en-us/library/ms176057.aspx –

+0

Es klingt genau wie Sie sagen "Betreff", dann "Frage" –

Verwandte Themen