Come aggiornare in modo incrementale un database durante la distribuzione di un sito Web?

La risposta di Jelayn è piuttosto buona e rappresenta una pratica approssimativa, specialmente nel mondo di Rails, in cui una soluzione simile viene inserita nel framework. Tuttavia, lo stato dell'arte, come praticato da Facebook, Flickr, Heroku e IMVU - un pioniere in questo - è un po 'più avanzato.

Il problema con la pratica standard è che presuppone che tu possa scrivere 2 versioni di codice e passare da una all'altra con una migrazione rapida durante la distribuzione. Ci sono molti problemi con questo:

• Se disponi di molti dati, una migrazione richiederà del tempo. Ci sono voluti mesi per la migrazione dei dati da parte di Facebook, ma a meno che tu non abbia pochi dati, è raro che la migrazione sia istantanea. La soluzione a questo è migrare lentamente. IMVU ha aperto la strada alla strategia qui:

  • invece di migrare la tabella, creare una tabella separata con il nuovo schema
  • quando viene letta una riga che non è presente nella nuova tabella, migrare solo quella riga e salvarla nella nuova tabella. Puoi quindi eliminare la vecchia riga.
  • esegue anche un processo in background che esegue le migrazioni in batch (fai attenzione ai conflitti!)

• durante una migrazione, il tuo codice deve supportare il vecchio schema e quello nuovo. Quindi dovresti scrivere il codice che supporta entrambi, quindi eseguire la migrazione, quindi rimuovere il vecchio codice in una distribuzione separata.

• in caso di migrazione fallita, dovresti decidere se è possibile eseguire la migrazione in entrambe le direzioni o solo in avanti. IMVU va avanti solo credo - quindi se hanno un bug nella loro migrazione, lo aggiustano invece di ripristinarlo. Personalmente preferisco il fixing, ma ci sono buoni argomenti per il rollback anche.

Questo materiale è strettamente correlato anche alla distribuzione continua e molte di queste strategie possono essere d'aiuto. Ad esempio, una tecnica comune per i CD abilita selettivamente il nuovo codice solo a una piccola base di utenti per dare più test e solo successivamente abilitarlo per un pubblico sempre più ampio (in genere, si utilizza un'impostazione di DB per ogni funzione). Questa pratica ti consente di acquisire maggiore fiducia nelle tue migrazioni, specialmente quando sono più complicate di una semplice aggiunta di un campo e senza scommettere tutti i tuoi dati su una migrazione relativamente non testata.

Fonte : ricerche di mercato e conversazioni con i clienti durante l'avvio della mia integrazione continua e distribuzione .

Sono d'accordo con @FrustratedWithFormsDesigner nel senso che è del tutto possibile, E che lo script per l'aggiornamento della struttura del database non dovrebbe essere accompagnato dal codice dell'applicazione. Per questo motivo l'applicazione richiede altre autorizzazioni che consentono di creare tabelle, modificare tabelle, ecc. Che probabilmente non sono necessarie durante l'utilizzo "normale" dell'applicazione. Quindi, in termini di sicurezza, non è una buona cosa, dal momento che l'applicazione dovrebbe avere solo le autorizzazioni necessarie per funzionare correttamente.

Comunque, torniamo al punto principale. È abbastanza possibile farlo correttamente creando una tabella speciale nel tuo database, diciamo X_VERSION, in cui avrai semplicemente la versione corrente dello schema del database (potrebbe anche essere un timestamp). Ogni volta che si modifica lo schema del database, si inserisce tale modifica in uno script SQL denominato [Timestamp-XXX-WhateverItIsYouAreDoing.sql], dove:

• Timestamp è il timestamp, ad esempio 20110111-165500
• XXX è un numero, che sarà utile in seguito per conoscere l'ordine di esecuzione degli script
• Qualunque cosa, ecc. è un testo che ti aiuterà a ricordare ciò che fai in quello script

Se il tuo programma di aggiornamento del database è nella tua applicazione o al di fuori non importa per i seguenti passaggi; ogni volta che fornisci una nuova versione della tua applicazione, il tuo programma di aggiornamento dovrebbe fare questo:

• Cerca il timestamp attuale in X_VERSION
• Controlla tutti gli script che devono essere eseguiti tra la versione trovata in X_VERSION e la nuova versione

• Passa sopra gli script e per ogni script

  • Esegui lo script aggiornando il tuo database / schema
  • Aggiorna il timestamp in X_VERSION al timestamp dello script eseguito

Quando tutti gli script sono terminati, sai che la tua applicazione può essere avviata in sicurezza.

Bonus : Se vuoi avere un modo sicuro per tornare a una versione precedente, ogni volta che crei uno script che altera il tuo database, crea sempre da qualche parte uno script che ti permetta di tornare alla versione precedente. A volte può essere un po 'difficile (ad esempio rimuovere una colonna, non tutti i DBMS lo consentono), ma provare sempre. Sarai quindi pronto a ripristinare una versione precedente, se necessario.

Di solito ho modifiche db distribuite all'esterno dell'applicazione principale, solitamente tramite uno script che viene eseguito dal DBA.

Suppongo che potresti apportare le modifiche dall'interno dell'applicazione, se la tua applicazione ha il permesso di modificare la struttura del database. Immagino che cosa dovrebbe succedere all'avvio dell'applicazione, che una nuova procedura venga eseguita all'avvio, esegua tutte le modifiche necessarie al database e quindi possa essere riavviata. Il trucco è assicurarsi che le modifiche avvengano solo una volta . Questo potrebbe probabilmente essere fatto controllando un numero di versione in una tabella speciale e usandolo per decidere se il database dovrebbe essere modificato.

Aggiunge anche le attività di manutenzione di db all'applicazione principale, che IMO non è una buona idea perché l'applicazione è probabilmente progettata per fare qualcos'altro (bloggin, banche, cartelle cliniche mediche, prenotazioni alberghiere online, ecc ...). A volte potresti voler mantenere le distribuzioni del tuo database completamente separate dall'applicazione principale.

Da un punto di vista tecnico, è abbastanza possibile farlo. Dovrebbe essere fatto? Questa è una domanda diversa.

I due approcci standard per gli aggiornamenti del database che ho visto applicati sono:

1. Il team di distribuzione che esegue script sql forniti dal team DBA. Il gruppo DBA fornirebbe script per aggiornare lo schema e caricare tutti i dati richiesti per quel particolare rilascio.
2. Utilizzo di uno strumento automatico come Liquibase. Questo sistema aggiunge una tabella simile a ciò che @Jalayn propone, che tiene traccia dei changeset (delta) che dovrebbero essere eseguiti per ogni tabella. La maggior parte delle operazioni standard sono supportate.

In entrambi i casi, il risultato finale dovrebbe essere lo stesso. Tuttavia, l'approccio che prendi dovrebbe riflettere i principi che il tuo gruppo di sviluppo preferisce: automatizzato vs manuale, ecc.