Работил съм предимно в разработването на бизнес приложения и управлението на конфигурацията. Вашият въпрос е представителен за предизвикателствата в такава среда; когато надграждате например Microsoft Word, не е необходимо да променяте всички документи веднага от doc в docx. И документите дори имат по-проста структура, пълна база данни за връзки.
Не е така за бизнес приложенията; потребителите пропускат версии, правят неоторизирани промени в модела на данните и системата трябва да продължи да работи и да предоставя правилните номера...
Ние използваме за нашите собствени приложения (най-голямото е като 600 таблици) самостоятелно разработен CASE инструмент, който включва разклоняване/сливане, но подходът може да се направи и ръчно.
Модел на данни за версия
Моделът на данните може да бъде записан по структуриран начин. Например като съдържание на таблица (CSV за зареждане в таблица с мета данни) или като код, който открива използваната версия и добавя колони и таблици, когато липсват, включително нетривиални миграции.
Това дори позволява на няколко потребители едновременно да променят модела на данните.
Когато използвате автоматично откриване (например, ние използваме повикване с име "verify_column" вместо "add_column"), това дори позволява плавна миграция, независимо от номера на версията, от която клиентът започва надстройката. Такава процедура анализира таблицата, която трябва да бъде променена, и издава правилния DDL, като например alter table t1 add col1 number not null когато липсва колона или alter table t1 modify col1 not null когато колоната вече е присъствала, но е нула.
За Oracle и SQL Server мога да ви предоставя няколко примерни процедури. В MySQL бих кодирал това, използвайки език от страна на клиента, за предпочитане независим от ОС, за да позволя на инсталациите да работят на Windows и Linux. Може би да използвате Apache Ant, когато имате опит с това.
Данни за версии
Разделяме таблиците в четири категории:
- R:референтни данни; данни, които сайтът на приложението трябва да предостави, преди действително да използва системата. Например кодове на сметки в главната книга. Референтните данни рядко се променят след пускане в реално време и не нарастват непрекъснато. Съдържанието отразява бизнес модела на сайта, където се използва приложението.
- T:данни за транзакциите; данни, които сайтът регистрира, променя и премахва по време на използване на приложението. Например записи в главната книга. Данните за транзакциите започват от 0 и нарастват непрекъснато. Когато компанията удвои приходите си, данните за транзакциите също се удвояват.
- S:заложени данни; данни НЕ се поддържат от потребителя на сайта, но се предоставят и поддържат от развиващата страна. По същество това е код, превърнат в данни. Например, 'F' означава 'Женски'. Грешките в заложените данни могат да доведат до системни грешки.
- O:останалото (в идеалния случай не е необходимо, тъй като са технически, но някои системи изискват временна таблица A или скреч таблица B).
Съдържанието на таблици от категория 'S' (зададени данни) се поставя под контрол на версиите. Обикновено ги регистрираме като метаданни в нашия инструмент за случаи, след което се наричат „набори от данни“, но можете също да използвате например Microsoft Excel или дори код.
Например, в Excel ще имате списък с редове със засадени данни. В колона А можете да въведете функция на Excel като =B..&"|"&C..& "|" & ... който обединява всичко и го прави подходящ за зареждане от инструмент за зареждане.
Например в кода може да имате обаждане като:
verifySeed('TABLE_A', 'CODE', 'VALUE')
Excel е малко трудно да се постави под контрол на версиите, което позволява на множество потребители да променят съдържанието по едно и също време. Подходът с кода е много прост.
Моля, не забравяйте също да добавите функции за премахване на остарели данни. Например чрез изрично изброяване на остарели първоначални данни или чрез автоматично премахване на всички заредени данни, които присъстват в таблиците, но не са докоснати от последната инсталация.
