Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

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

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

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
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
І знайти готову бібліотеку під вашу мову/фреймворк ...

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

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

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

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

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

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

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