Domanda

Sono in una situazione in cui è in arrivo una nuova versione di software che utilizzerà un database separato (modifiche significative nello schema) rispetto al vecchio. Ci sarà un considerevole periodo di tempo in cui sia il nuovo che il vecchio sistema saranno in produzione e dobbiamo assicurarci che vengano generati ID univoci tra i due database (non vogliamo una riga nel database A avere lo stesso ID di una riga nel database B). I database sono Sybase.

Possibili soluzioni che ho escogitato:

  1. Utilizza un tipo di dati che supporti numeri molto grandi e alloca un intervallo per ciascuno, sperando che non trabocchi mai.
  2. Utilizza valori negativi per un database e valori positivi per l'altro.
  3. Aggiunta di una colonna aggiuntiva che identifica il database e utilizza la combinazione di quello e l'ID corrente come chiave.
  4. Cry.

Cos'altro potrei fare? Esistono soluzioni più eleganti, in qualche modo affinché i due database funzionino insieme? Credo che i due database saranno sullo stesso server, se questo è importante.

È stato utile?

Soluzione

L'ho visto accadere alcune volte. Per quelli con cui ero coinvolto, abbiamo semplicemente assegnato uno spazio ID sufficientemente grande per quello vecchio (poiché era in funzione da un po 'di tempo, e sapevamo quante chiavi aveva usato, potevamo calcolare quante più chiavi avesse avrebbe bisogno di una 'durata di vita' specifica) e ha iniziato la "SEQUENZA ID" " del nuovo database sopra quello.

Vorrei raccomandare contro tutti gli altri trucchi, se non altro perché tutti richiedono modifiche all'app 'legacy', il che è un rischio che non vedo la necessità di prendere.

Altri suggerimenti

I GUID o gli ID univoci globali possono essere utili chiavi primarie in questo tipo di casi. Credo che Sybase li supporti.

Modifica: anche se se l'intero database è già basato su chiavi primarie intere, il passaggio a GUID potrebbe non essere molto pratico - in tal caso basta dividere lo spazio intero tra i database, come hanno suggerito GWLlosa e altri.

Nel tuo caso, prenderei in considerazione l'utilizzo di uniqueidentifier (GUID) come tipo di dati. Sono considerati unici quando li crei utilizzando funzione di sistema newid () .

CREATE TABLE customer (
   cust_key UNIQUEIDENTIFIER NOT NULL
            DEFAULT NEWID( ),
   rep_key VARCHAR(5),
   PRIMARY KEY(cust_key))

Effettua il pre-seeding del tuo nuovo database con un # maggiore di quello che raggiungerà il tuo vecchio database prima di unirli.

L'ho fatto in passato e il volume dei record era ragionevolmente basso, quindi ho iniziato il mio nuovo database a 200.000 come numero di record iniziale. poi, quando è arrivato il momento, ho appena migrato tutti i vecchi record nel nuovo sistema.

Ha funzionato perfettamente!

I GUID sono progettati per questa situazione.

Se creerai un numero simile di nuovi elementi su ciascun database, puoi provare ID pari su un database, ID dispari nell'altro.

Utilizza il tipo di dati UNIQUEIDENTIFIER. So che funziona in MS SQL Server e per quanto posso vedere da Google, Sybase lo supporta.

http://www.ianywhere.com/developer/product_manuals /sqlanywhere/0902/en/html/dbrfen9/00000099.htm

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top