Как реализовать семантическое версионирование?

Здравствуй, Тостер!
Есть таблицы данных 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

В чём проблема? теперь, при выборе версии, нужно показывать актуальные для этой версии данные, а также всю историю изменений до этого. А ещё, если мы начнём изменят предыдущие мажорные версии, или патчить прошлые минорные, это не должно сказываться на истории новых версий и т.д. думаю суть уже ясна.

Проблема вроде как типовая, но не могу найти литературу или понять как это правильно реализовывается. Может кто знает?
  • Вопрос задан
  • 1397 просмотров
Решения вопроса 1
Serhioromano
@Serhioromano
Web Developer
Это не совсем правильно вот так делать версии базы в соответсвии с изменинями. Это логически не верный подход. Что если например вам нужно убрать изменине 0.1.1 но не тронуть друние? Вы знаете что имя реально было Петяъ, вам нужно это вернуть но остваить Магомета? Если вы откатитесь, то потеряете другие записи.

По этому контроль версий на базы обычно делают в форме Журнала Аудита (Audit Log) который храни кто и что когда сделал, что на что поменял и т.д. И тут можно сделать функцию вернуть изменение назад, или воставноить удаление, но при этом можно работать с каждым конкретным случаем не затранивая другие. Журнал можно хорошо организвать и фильтровать по тиау действий, пользователям, группам пользователй, таблицами, и.д. Так тчо найти нужное действие в журнале будет не сложно.

Если же вам нужно тупо откатывать базу к прошлому состоянию то нет смыла вообще делать версии 3 уровней 1.1.1. Можно вообще сквозную нумерацию или вообще как версию иметь точку времени. Но судя по тому что вы отталкиваетесь от изменений самих данных то вам нужен журнал аудита.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
PretorDH
@PretorDH
HTML5, CSS3, PHP, JS - люблю в чистом виде.
А прописать seed и коммитить в репозиторий.

Почитайте в ларавель как реализовано.

Для структуры базы есть Migrations....

А для снепшотов из базы, нужно уже искать/писать модуль на уровне реализации... Например...

Если вы имеете ввиду уровень самой базы.
Ищите реализации версионности структуры через view или встроенные процедуры: Например... и Второй пример...

В wordpress реализована версионность на примитивном уровне и только материалов. Тоже можно посмотреть/поанализировать.
Ответ написан
@BorisKorobkov Куратор тега MySQL
Web developer
при выборе версии, нужно показывать актуальные для этой версии данные, а также всю историю изменений до этого. А ещё, если мы начнём изменят предыдущие мажорные версии, или патчить прошлые минорные, это не должно сказываться на истории новых версий и т.д.

Используйте git, hg или другие системы контроля версий.
Данные - в миграциях.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы