Zajmowałem się głównie tworzeniem aplikacji biznesowych i zarządzaniem konfiguracją. Twoje pytanie jest reprezentatywne dla wyzwań w takim środowisku; kiedy aktualizujesz na przykład Microsoft Word, nie musisz od razu zmieniać wszystkich dokumentów z doc na docx. A dokumenty mają nawet prostszą strukturę, pełną relacyjną bazę danych.
Nie dotyczy to aplikacji biznesowych; użytkownicy pomijają wydania, wprowadzają nieautoryzowane zmiany w modelu danych, a system musi działać dalej i podawać prawidłowe liczby...
Do naszych własnych aplikacji (największa ma 600 tabel) używamy samodzielnie opracowanego narzędzia CASE, które obejmuje rozgałęzianie/scalanie, ale podejście można również wykonać ręcznie.
Model danych wersji
Model danych można zapisać w ustrukturyzowany sposób. Na przykład jako zawartość tabeli (CSV do załadowania w tabeli z metadanymi) lub jako kod, który wykrywa używaną wersję i dodaje kolumny i tabele, gdy ich nie ma, w tym nietrywialne migracje.
Pozwala to nawet wielu użytkownikom na jednoczesną zmianę modelu danych.
Kiedy używasz automatycznego wykrywania (na przykład używamy wywołania o nazwie „verify_column” zamiast „add_column”), umożliwia to nawet płynną migrację niezależnie od numeru wersji, od którego klient rozpoczyna aktualizację. Taka procedura analizuje tabelę, która ma zostać zmieniona i wydaje poprawne DDL, takie jak alter table t1 add col1 number not null gdy brakuje kolumny lub alter table t1 modify col1 not null kiedy kolumna była już obecna, ale dopuszczalna do wartości null.
Dla Oracle i SQL Server mogę przedstawić kilka przykładowych procedur. W MySQL zakodowałbym to przy użyciu języka po stronie klienta, najlepiej niezależnego od systemu operacyjnego, aby umożliwić uruchamianie instalacji w systemach Windows i Linux. Może użyjesz Apache Ant, jeśli masz z tym doświadczenie.
Dane dotyczące wersji
Stoły dzielimy na cztery kategorie:
- R:dane referencyjne; dane, które strona aplikacji musi podać przed faktycznym skorzystaniem z systemu. Na przykład kody kont księgi głównej. Dane referencyjne rzadko zmieniają się po uruchomieniu i nie stale rosną. Treść odzwierciedla model biznesowy witryny, w której używana jest aplikacja.
- T:dane transakcyjne; dane, które witryna rejestruje, zmienia i usuwa w trakcie korzystania z aplikacji. Na przykład wpisy księgi głównej. Dane transakcyjne zaczynają się od 0 i stale rosną. Gdy firma podwaja przychody, dane transakcyjne również się podwajają.
- S:dane początkowe; dane NIE utrzymywane przez użytkownika w witrynie, ale dostarczane i utrzymywane przez stronę rozwijającą. Zasadniczo jest to kod zamieniony na dane. Na przykład „F” oznacza „kobieta”. Błędy w wprowadzonych danych mogą prowadzić do błędów systemowych.
- O:reszta (najlepiej nie potrzebna, ponieważ są techniczne, ale niektóre systemy wymagają tymczasowej tabeli A lub tabeli zdrapek B).
Zawartość tabel kategorii „S” (dane rozstawione) jest pod kontrolą wersji. Zwykle rejestrujemy je jako metadane w naszym narzędziu do spraw, a następnie nazywamy „zestawami danych”, ale możesz także użyć na przykład Microsoft Excel lub nawet kodu.
Na przykład w Excelu miałbyś listę wierszy z zastawionymi danymi. W kolumnie A możesz wpisać funkcję Excela, taką jak =B..&"|"&C..& "|" & ... który łączy wszystko i sprawia, że nadaje się do ładowania przez narzędzie ładujące.
Na przykład w kodzie możesz mieć wywołanie takie jak:
verifySeed('TABLE_A', 'CODE', 'VALUE')
Excel jest trochę trudny do objęcia kontrolą wersji, umożliwiając wielu użytkownikom zmianę zawartości w tym samym czasie. Podejście z kodem jest bardzo proste.
Pamiętaj, aby dodać również funkcje, aby usunąć przestarzałe, zaszczepione dane. Na przykład, jawnie wyszczególniając przestarzałe dane wyjściowe lub automatycznie usuwając wszystkie dane początkowe obecne w tabelach, ale nienaruszone podczas ostatniej instalacji.
