Wersjonowanie danych Mysql (nie tylko schematu)

Question

W moim biurze pojawiła się dyskusja na temat tworzenia pakietu kontrolującego dane mysql w wersji (nie schematy/migracje).

Zasadniczo proces będzie działał w ten sposób. Należy pamiętać, że klient nadal używa backendu jako normalnego obrazu, a następnie używa go tak, jak backend wordpress. Klient logowałby się, wybierz "oddział", nadając mu nazwę, powiedzmy "nowi użytkownicy", i sklonowałby całkowicie nową bazę danych, umożliwiając użytkownikowi pracę w "filii" bez wpływu na żywo. Gdy klient skończy wprowadzanie zmian danych, scalą gałąź danych w "master" (na żywo).

Pod oknem podczas scalania wyeksportuje dane z gałęzi "na żywo" i "nowych użytkowników" do pliku sql i wykona różnicę svn i scali zmiany.

Sytuacja, która wywołała ten pomysł, polegała na tym, że mamy klientów, którzy muszą wprowadzić zmiany w witrynie, ale nie chcą umieszczać tych danych na żywo, a podczas wprowadzania zmian nie chcą wprowadzać zmian w witrynach innych współpracowników. zarówno. Zasadniczo powielono to, co robią programiści podczas pracy w repozytoriach takich jak Git.

Również, jeśli klient pracuje na stronie dev/demo, praca, którą wykonują, chce umieścić na żywo.

Chciałem otworzyć dyskusję, aby zrozumieć, czy to nawet dobry pomysł? Jakie problemy możemy napotkać? Czy jest to dobra praktyka programowania podczas pracy z danymi? Czy coś takiego już istnieje?

Answer 1

Baza danych (szczególnie ich dane) rzadko są przechowywane w systemie kontroli wersji, ponieważ nie skaluje się dobrze dla dużych baz danych.

W twoim przypadku, jeśli nie masz too wiele danych, które mogłyby pracować, zwłaszcza, że ​​w mysqldump can produce a delimited text format (który ma szansę Diff przeciwko poprzedniej wersji)

chciałbym jeszcze polecić oddzielny repo git oraz dedykowane narzędzie do zarządzania zarówno zmianami w schemacie, jak i danych. Na przykład LiquidBase może zapewnić "kontrolę źródła dla twojej bazy danych".
Masz również, jako dedykowaną wyspecjalizowaną bazę danych: off-scale.

Jeśli robisz to ręcznie, to masz dobre praktyki podsumowane w "Recipes for Continuous Database Integration".

Jak mentioned here, nawet dla schematu:

dowiedziałem się na własnej skórze, że zastosowanie zmiany schematu bazy danych nie może być wiarygodnie zrobić bez kompleksowego planu krok po kroku i, podobnie postanowienie z zależnościami relacjami są ważny.
Po prostu przechowywanie "bieżącego" lub "końcowego" schematu nie jest wystarczające. Istnieje wiele zmian, które nie mogą być zastosowane z mocą wsteczną, bez znajomości A->B->C, a niektóre zmiany B mogą obejmować logikę migracji lub poprawki.

Answer 2

Czy wymagania jak po prostu w następujący sposób:

• sam kod back-end;
• Używaj danych wzorcowych na żywo;
• Użytkownicy końcowi (lub grupa) do pracy na danych izolowanych;
• Brak migracji, użytkownicy końcowi mogą modyfikować tylko dane (DML) i nie mogą modyfikować schematu (DDL);

Jeśli są to wymagania, można użyć wielu baz danych. Rozważmy następujące bazy danych na serwerze MySQL:

• masterdb
• branch_demo
• branch_brian
• branch_sandbox
• ...

tych baz dzielić dokładnie ten sam schemat, a tylko dane są różne. W każdej branży, mamy specjalną tabelę (tj dbinfo), aby śledzić oddziału macierzystego (prawdopodobnie masterdb), tworzyć datetime i inne szczegóły, takie jak poziom-dostępu itp

• id
• BRANCHNAME
• parent_branch
• created_on
• lastmod_on

można zezwolić użytkownikom końcowym do pracy na oddzielnych gałęziach, po prostu pozwalając im s wybierz konkretną bazę danych w interfejsie użytkownika, gdzie masterdb jest domyślnie wybrany i jest używany w LIVE.

• Utworzenie nowego oddziału byłoby tak proste, jak klonowanie bazy danych;
• Połączenie nowej gałęzi z masterem może być obsługiwane za pomocą instrukcji REPLACE w MySQL;

Jeśli chcesz śledzić zmiany danych, możesz utworzyć specjalną tabelę do rejestrowania aktywności.