Gestione dei dati di produzione

2

Abbiamo un requisito per una nuova funzionalità che richiede che alcuni dati seme siano presenti nel database (in pratica alcuni valori predefiniti) affinché la funzione funzioni correttamente. Abbiamo questo in 2 diversi scenari al momento, e il miglior metodo di generazione / inserimento dei dati seme sembra variare a seconda dell'archivio dati che usiamo. Non sto parlando di seminare dati per scopi di test qui.

Ad esempio, alcune funzionalità richiedono che le tabelle siano presenti in SQL Server. Stiamo usando le migrazioni manuali tra le versioni (fondamentalmente diffondendo gli schemi), quindi inserire i dati seme per questo avrebbe senso essere fatto nello stesso script SQL che aggiorna lo schema. Il modo in cui alcuni ORM sembrano gestire questo è di avere un metodo Seed () (o equivalente) nel codice di inizializzazione che creerà i dati.

Una funzione diversa è l'utilizzo di Azure Table Storage (ATS) come archivio dati. Essendo senza schema, non c'è nessuno script per creare la tabella qui, ma l'applicazione controlla l'esistenza delle tabelle al primo avvio e le crea se non esiste lì. Ciò significa che normalmente non creiamo le tabelle prima che l'implementazione proceda. Per seminare dati in ATS potremmo pre-compilare l'ambiente (che richiederebbe che qualche codice sia scritto ed eseguito da qualche parte) o potremmo fare in modo che il componente che controlla l'esistenza della tabella inserisca i dati così come sono stati creati.

C'è uno svantaggio a lungo termine nell'avere i dati seme in classi nel codice, e se questo è il posto migliore per metterlo insieme, sarà più sensato tenere insieme i dati (ad es. avere una classe Seed con il dati in esso contenuti all'avvio dell'app) o il Repository ha la responsabilità di assicurarsi che i dati di base esista prima di inviare qualsiasi domanda?

    
posta Matthew Steeples 16.06.2016 - 12:38
fonte

3 risposte

1

Direi di no, non inserire questo nel codice se inserendolo nel codice significa che all'avvio dell'applicazione rileva che è necessario inizializzare il DB e farlo. Ci sono alcuni motivi per questo (alcuni saranno simili o uguali a quelli forniti da Alpha):

  • Come ho capito, deve essere eseguito esattamente una volta in produzione. Avere questa procedura nel codice non ha valore dopo quella prima esecuzione.
  • Nel corso del tempo, nessuno ricorderà a cosa serve questo codice o perché è stato lì. Le nuove persone (o anche coloro che ne erano a conoscenza contemporaneamente) lo vedranno e pensano "WTF? È questo". Lo scenario migliore è che qualcuno lo rimuove dal controllo del codice sorgente.
  • Se per qualche motivo qualcosa va storto e l'app si presenta in uno stato in cui rileva una nuova installazione, la eseguirà di nuovo e continuerà a farlo felicemente. Questo non è desiderabile. Fail failure . Potrebbe essere un vero casino pulire se l'applicazione viene eseguita in quello stato per un po 'di tempo.

Questo dovrebbe essere parte della distribuzione del codice, non parte del codice. Questo rende deliberata la creazione del seme.

    
risposta data 22.07.2016 - 23:33
fonte
1

In realtà hai bisogno di due cose:

  • Un meccanismo che decide che è necessaria un'azione (ad esempio, i dati seme devono essere aggiunti)
  • I dati seme e un codice che trasferiscono i dati seme nell'archivio di destinazione (ovvero sql-script o csv-data + csv-interpreter)

Vorrei risolvere il problema in questo modo:

  • Aggiungi un numero di versione nello spazio di archiviazione di destinazione
  • Definisci una convenzione di denominazione per gli script di modifica della versione
    • L'esempio version-update-1-2.sql si aggiornerebbe dalla versione 1 alla versione 2
    • Esempio version-update-1-2.exe (se il processo non è non programmabile (eseguito attraverso un interprete)
  • L'ultimo passaggio in version-update- * imposterà il nuovo numero di versione.
  • All'avvio del programma, il codice controlla se è disponibile un aggiornamento ed eseguirlo.
  • Gli script di aggiornamento possono essere rimossi safaly una volta eseguiti correttamente.

Se aggiungi una funzione al tuo prodotto

  • aumenta il numero della versione dei dati
  • fornisce uno script di aggiornamento che corrisponde alla convenzione di denominazione.

Is there a long term disadvantage to having the seed data in classes in the code, and if that's the best place to put it

  • pro il codice è autonomo. È molto probabile che l'aggiornamento continui a peggiorare dopo alcuni anni.
  • contra È più difficile rimuovere i passaggi di aggiornamento. nel tempo il codice diventa sempre più ingombrante.
  • contra vecchi passaggi di aggiornamento potrebbero interrompersi se il sistema cambia.
risposta data 21.09.2016 - 12:35
fonte
0

Is there a long term disadvantage to having the seed data in classes in the code, and if that's the best place to put it

Direi che, al contrario, questo è il posto migliore per avere questo tipo di inizializzazione. Poiché il tuo codice dipende direttamente da questi dati, dalla sua forma e dai suoi contenuti, questa inizializzazione essendo direttamente legata al tuo codice è in realtà la cosa migliore che potrebbe esserti successo.

Tuttavia, nessuno di solito lo fa. Di solito, dovresti creare uno script o una fase di distribuzione, per un paio di motivi:

  1. Il codice di inizializzazione non ha bisogno di essere eseguito tutto il tempo. Codificare questo per un particolare scenario di una volta non è di solito molto fruttuoso. Ricorda che incorporarlo nel tuo codice base significa che deve essere mantenuto e testato anche.
  2. Una volta terminata l'inizializzazione in ambienti reali, sei bloccato a un determinato insieme di contenuti, a meno che tu non abbia un modo di gestire le modifiche ai dati, e questo è qualcosa che un semplice codice di inizializzazione non funzionerà da solo .

Un esempio di ciò che viene preso in considerazione nella codebase sono le migrazioni di Entity Framework o Rails. Inizializzano, aggiornano e seminano e trasformano i dati.

L'archiviazione effettiva non ha importanza. Le tabelle di Azure possono essere schematiche, ma il tuo codice richiederà la presenza di un certo schema per poter lavorare con quei dati.

Detto questo, i miei consigli sono:

  1. Se possibile, includi questa logica seme nel tuo codice. Preparati a mantenere quei dati e le modifiche ad esso. Preparati per vecchi dati ambientali. Preparati a migrare avanti e indietro.
  2. Se puoi delegare a un framework noto, fallo. Ci vorrà molto del tuo codice.
  3. Non includere questa logica nei repository. Dovrebbero occuparsi dell'accesso ai dati, non dell'inizializzazione dell'origine dati.
risposta data 22.06.2016 - 13:34
fonte

Leggi altre domande sui tag