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.