Mysql
 sql >> Database >  >> RDS >> Mysql

Versione database/Controllo modifiche per dati non schema?

Ho lavorato principalmente nello sviluppo di applicazioni aziendali e nella gestione della configurazione. La tua domanda è rappresentativa delle sfide in un tale ambiente; quando si aggiorna, ad esempio, Microsoft Word, non è necessario modificare immediatamente tutti i documenti da doc a docx. E i documenti hanno anche una struttura più semplice, un database di relazioni completo.

Non così per le applicazioni aziendali; gli utenti saltano le versioni, apportano modifiche non autorizzate al modello di dati e il sistema deve continuare a funzionare e fornire i numeri corretti...

Utilizziamo per le nostre applicazioni (quella più grande è come 600 tabelle) uno strumento CASE auto-sviluppato che include branching/merging, ma l'approccio può essere eseguito anche manualmente.

Modello dati di versione

Il modello dati può essere scritto in modo strutturato. Ad esempio come contenuto di una tabella (CSV da caricare in una tabella con metadati) o come codice che rileva la versione in uso e aggiunge colonne e tabelle quando mancanti, comprese le migrazioni non banali.

Ciò consente anche a più utenti contemporaneamente di modificare il modello di dati.

Quando utilizzi il rilevamento automatico (ad esempio, utilizziamo una chiamata denominata "verify_column" anziché "add_column"), ciò consente anche una migrazione senza problemi indipendentemente dal numero di versione da cui il cliente sta avviando l'aggiornamento. Tale procedura analizza la tabella da modificare ed emette il DDL corretto come alter table t1 add col1 number not null quando manca una colonna o alter table t1 modify col1 not null quando la colonna era già presente ma nullable.

Per Oracle e SQL Server posso fornirti alcune procedure di esempio. In MySQL lo codificherei usando un linguaggio lato client, preferibilmente indipendente dal sistema operativo per consentire l'esecuzione delle installazioni su Windows e Linux. Magari usando Apache Ant quando ne hai esperienza.

Dati sulla versione

Dividiamo le tabelle in quattro categorie:

  • R:dati di riferimento; dati che il sito dell'applicazione deve fornire prima di utilizzare effettivamente il sistema. Ad esempio, codici conto di contabilità generale. I dati referenziali cambiano raramente dopo il go live e non crescono continuamente di dimensioni. I contenuti riflettono il modello di business del sito in cui viene utilizzata l'applicazione.
  • T:dati di transazione; dati che il sito registra, modifica e rimuove durante l'uso dell'applicazione. Ad esempio, i movimenti di contabilità generale. I dati della transazione iniziano da 0 e crescono continuamente. Quando l'azienda raddoppia i ricavi, raddoppiano anche i dati sulle transazioni.
  • S:dati seminati; dati NON conservati dall'utente nel sito ma forniti e mantenuti dallo sviluppatore. Essenzialmente questo è il codice trasformato in dati. Ad esempio, "F" sta per "Femmina". Gli errori nei dati iniziali possono portare a errori di sistema.
  • O:il resto (idealmente non necessario, dato che sono tecnici, ma alcuni sistemi richiedono un tavolo temporaneo A o uno scratch table B).

Il contenuto delle tabelle della categoria 'S' (dati seed) è posto sotto il controllo della versione. Normalmente li registriamo come metadati nel nostro strumento Case, quindi denominato "set di dati", ma puoi anche utilizzare ad esempio Microsoft Excel o persino codice.

Ad esempio, in Excel avresti un elenco di righe di dati seminati. Nella colonna A potresti inserire una funzione di Excel come =B..&"|"&C..& "|" & ... che concatena il tutto e lo rende adatto al caricamento tramite uno strumento caricatore.

Ad esempio nel codice, potresti avere una chiamata del tipo:

verifySeed('TABLE_A', 'CODE', 'VALUE')

Excel è un po' difficile da portare sotto il controllo della versione, consentendo a più utenti di modificare i contenuti contemporaneamente. L'approccio con il codice è molto semplice.

Ricorda di aggiungere anche funzionalità per rimuovere i dati seminati obsoleti. Ad esempio, elencando in modo esplicito i dati di seeding obsoleti o rimuovendo automaticamente tutti i dati di seeding presenti nelle tabelle ma non toccati dall'ultima installazione.