ThinkStage Conference — 30+ speakers about BA, Product, UX. Regular price ends May, 24.
×Закрыть

Схема базы данных в рамках VCS

У нас есть сложная схема базы данных в виде EER диаграммы в формате MySQL Workbench .mwb, которая периодически изменяется. Поэтому хотелось бы отслеживать изменения с помощью git, но так как формат файла диаграммы бинарный (на самом деле архив из кучи XML файлов) невозможно ни diff посмотреть, ни merge сделать.

Мы придумали хранить рядом с EER диаграммой SQL дамп этой же схемы. Это позволяет хотя бы понимать, какие изменения были произведены. Но по ощущениям, работа с таким симбиозом — ад.

А как вы отслеживаете изменения структуры БД? Используете ли вы EER диаграммы для визуализации структуры базы? В общем, любой совет будет полезен.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

en.wikipedia.org/wiki/Schema_migration
І знайти готову бібліотеку під вашу мову/фреймворк ...

Зачем перегонять в человеческий визуальный вид то, что потом хотите сравнить машинным способом, это же нонсенс
Сравниваете скрипты DDL базы в СВН, визуализация это побочный продукт
Разве что вы не храните DDL базы в svn а делаете деплой прям из воркбенча... тогда каждый раз перед деплоем делаете репорт по дифам и сохраняете в папку — это и будет ваш ресурс для отслеживания изменений

— а распаковать xml из .mwb и пофайлово сравнивать? минусом будет только то, что свой парсер элементов прийдется писать что бы представить в читабельном виде изменения в результате дифа
Задача в том виде в котором вы ее представили слишком кастомна, врядле есть универсальное коробочное решение сравнение .mwb

Единственная разница между альцгеймером и бюрократией — то что альцгеймер не заразен. А бюрократия заражает всю организацию.

Сделай дамп с опцией —no-data и порадуйся жизни. Поставь его на кронтаб, и анализируй его DIFFом сколько угодно.

Если серьёзно, есть очень простой и надёжный способ следить за изменениями: пустить их все через одного человека или команду, а остальным продакшен-базу трогать нельзя. Надо изменения — пишете скрипт, и в нужный день и час админы его проливают.

Визуализировать базу смысла НОЛЬ. Можно только в общих чертах составить диаграмму. Но чтобы передать всю логику базы, нужен естественный язык. Иначе говоря, модель базы столь же сложна, сколько логика самого процесса. Диаграмма полной модели займёт китайскую стену. А описание — документ килобайт на 200, ну может втрое больше если хранит ИСТОРИЮ изменений и ПОЯСНЕНИЕ кто и зачем изменения вносил.

В моих проектах это выглядит совсем банально: есть папка, куда просто по дате складываются изменения. Есть текстовый файл со структурой самой базы, без внутренностей таблиц, но с описанием какому процессу принадлежит каждая таблица. Это позволяет понимать, какие таблицы мусор, и находить те которые со временем теряют свою боевую нагрузку при переформатировании задач. Удобство в чём: банальным текстовым поиском можно найти КТО И ЗАЧЕМ создавал или вносил изменения. Отдельное удобство — в датах на будущее хранятся планы убить некоторые данные или таблицы, с указанием ответственного. Очень помогает при регулярной ревизии ≈ раз в полгода.

Отдельная фенечка баз, которая у тебя не найдёт отражение в диаграмме — это регулярные процедуры. Такие, которые чистят базу от естественного мусора, и перегужают устаревающие данные в более удобоваримые форматы. Например, суточная статистика ведётся сырым логом, а ночью делается агрегация. Или к примеру, надо вычистить из базы всё, что завязано на устаревшие куки пользователей. Как ты это в диаграмме рисовать собрался?

Подписаться на комментарии