Здравствуй, Тостер!
Есть таблицы данных A, B, C и т.д.. Так же есть критерии, по которым определяется как изменяется семантическая версия этого набора данных при изменении данных в A, B, C и т.д..
Начнём с примера:
у нас есть некий набор данных
в табл A - "Вася", в табл B - "Петяъ", в табл C - "Ахмед". Эта версия данных 0.1.0
Изменили "Петяъ" на "Петя", по критериям вышло, что нужно увеличить патч версию.
Теперь состояние БД:
в табл A - "Вася", в табл B - "Петя", в табл C - "Ахмед". Эта версия данных 0.1.1
Изменили "Вася" на "Василий". По критериям уже минорную увеличить надо
Теперь состояние БД:
в табл A - "Василий", в табл B - "Петя", в табл C - "Ахмед". Эта версия данных 0.2.0
Изменили "Ахмед" на "Магомед". По критериям уже мажорную увеличить надо
Теперь состояние БД:
в табл A - "Василий", в табл B - "Петя", в табл C - "Магомед". Эта версия данных 1.0.0
В чём проблема? теперь, при выборе версии, нужно показывать актуальные для этой версии данные, а также всю историю изменений до этого. А ещё, если мы начнём изменят предыдущие мажорные версии, или патчить прошлые минорные, это не должно сказываться на истории новых версий и т.д. думаю суть уже ясна.
Проблема вроде как типовая, но не могу найти литературу или понять как это правильно реализовывается. Может кто знает?
Это не совсем правильно вот так делать версии базы в соответсвии с изменинями. Это логически не верный подход. Что если например вам нужно убрать изменине 0.1.1 но не тронуть друние? Вы знаете что имя реально было Петяъ, вам нужно это вернуть но остваить Магомета? Если вы откатитесь, то потеряете другие записи.
По этому контроль версий на базы обычно делают в форме Журнала Аудита (Audit Log) который храни кто и что когда сделал, что на что поменял и т.д. И тут можно сделать функцию вернуть изменение назад, или воставноить удаление, но при этом можно работать с каждым конкретным случаем не затранивая другие. Журнал можно хорошо организвать и фильтровать по тиау действий, пользователям, группам пользователй, таблицами, и.д. Так тчо найти нужное действие в журнале будет не сложно.
Если же вам нужно тупо откатывать базу к прошлому состоянию то нет смыла вообще делать версии 3 уровней 1.1.1. Можно вообще сквозную нумерацию или вообще как версию иметь точку времени. Но судя по тому что вы отталкиваетесь от изменений самих данных то вам нужен журнал аудита.
почитал, но так и не понял причём тут seed. Он, как я понял, для заполнения начальными и тестовыми данными, а нам же нужно знать, как саму структуру БД построить и как с ней работать для поддержки семантического версионирования данных :)
при выборе версии, нужно показывать актуальные для этой версии данные, а также всю историю изменений до этого. А ещё, если мы начнём изменят предыдущие мажорные версии, или патчить прошлые минорные, это не должно сказываться на истории новых версий и т.д.
Используйте git, hg или другие системы контроля версий.
Данные - в миграциях.
так данные хранятся в бд, изменяются программно. И семантическое версионирование не реализовать. Да и приведенные данные это для понятности, там не всё так просто.
Простой
Средний
