Sunt o școală veche, în care folosesc fișiere sursă pentru crearea bazei de date. Există de fapt 2 fișiere - project-database.sql și project-updates.sql - prima pentru schema și date persistente, iar cea de-a doua pentru modificări. Desigur, ambele sunt sub controlul sursei.
Când se modifică baza de date, mai întâi actualez schema principală în project-database.sql, apoi copiați informațiile relevante în project-updates.sql, de exemplu, instrucțiunile ALTER TABLE.
Apoi pot aplica actualizările la baza de date de dezvoltare, testați, repetați până când se face bine.
Apoi, verificați fișierele, încercați din nou și aplicați producției.
De asemenea, am de obicei un tabel în db - Config - cum ar fi:
SQL
CREATE TABLE Config
(
cfg_tag VARCHAR(50),
cfg_value VARCHAR(100)
);
INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');
Apoi, adaug următoarele la secțiunea de actualizare:
UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';
Codul db_version devine modificat numai când baza de date este recreată, iar db_revision îmi oferă o indicație cât de departe db este în afara liniei de bază.
I could keep the updates in their own separate files, but I chose to mash them all together and use cut&paste to extract relevant sections. A bit more housekeeping is in order, i.e., remove ':' from $Revision 1.1 $ to freeze them.