Bandicoot
@Bandicoot
Вась-программист

Как правильно проводить «раскопки» сложной структуры БД на крупном проекте?

Допустим ситуация: мне нужно будет поддерживать крупный проект с БД с неясной структурой - большое количество таблиц (несколько десятков, а то и сотен), внешних ключей итд. Как максимально быстро и эффективно разобраться в ее структуре? Какие есть инструменты для визуализации связей между таблицами, независимо от их количества? Базы данных - MySQL и Postgres
  • Вопрос задан
  • 627 просмотров
Решения вопроса 5
DevMan
@DevMan Куратор тега MySQL
построение диаграммы со связями с рабочей базы - самый действенный вариант.
если таблиц много, сгруппировать их по возможности отдельными блоками.
затем все это дело распечатать и развесить на стенде/стене.
Ответ написан
alexey-m-ukolov
@alexey-m-ukolov Куратор тега MySQL
MySQL Workbench позволяет построить диаграмму БД из готовой схемы.
Ответ написан
sanchezzzhak
@sanchezzzhak
Ля ля ля...
Составляем список чего не понимаем
Задаем вопрос что база должна выполнять и как проект вообще должен работать.

Начинаем с пользователей дальше с сущностями както связываем, не понимаем смотрим код.
Подымаем контакты прошлых разработчиков, спрашиваем.
Ответ написан
В целом - создать несколько схем. Обычно работает примерно такая последовательность действий:

0. Начать с пустой глобальной схемы.

1. Внести в неё только названия таблиц. Разделить таблицы на основные бизнес-сущности, элементы агрегатов, справочники, таблицы связи и т. п. Чёткого алгоритма нет, интуитивно всё, глядя не только на схемы таблиц, но и на сами данные (если за пять лет работы в таблице 10 значений, то скорее всего это справочник), приложение, статистику СУБД и т. д.

2. Добавить в таблицы на схеме первичные и внешние ключи. Очень поможет, если есть основания полагать, что все внешние ключи реализованы средствами СУБД.

3. Сгруппировать таблицы по "модулям" (группам с предположительно схожей функциональностью), основной критерий группировки - внешние связи. В идеале на каждую группу должна быть одна внешняя связь от другой группы. Исключение - сквозные для приложения модули типа "Система разграничения прав" и(или) "Система аудита", ссылки на которые или из которых есть практически в каждой таблице.

4. Для каждого выявленного модуля (включая сквозные) создать отдельную схему, перенося с глобальной все вспомогательные таблицы модулей.

5. Детализировать по мере необходимости, если анализ делается для себя. Сразу, если для внешнего потребления.
Ответ написан
@Joysi75
  • 1. Сделайте копию для тестовой базы (или баз) и "копайте в ней"
  • 2. Составьте схему объектов и субъектов СУБД :
    • дерево таблиц и внешних ключей между ними
    • представления (view) и их построение
    • хранимых процедур/функций (укажите с какими таблицами работают)
    • триггеров (на какие таблицы и пр и каких действиях действуют)
    • периодических работ (job-ы и т.п.) - с какими объектами работают и что делают.
    • права и пользователи (кому и что доступно в БД).
    • внешние источники (файлы, импорт/экспорт).
    • и т.п.

  • 3. Найдите монитор запросов (tracer текущих запросов к БД или хотя бы анализатор логов).
  • 4. Настройте проект на работу с данной тестовой СУБД,
  • 5. Начните со справочников (обычно таблицы на которые имеются внешние ссылки и имеющие обычно простую структуру по типу id и name ). Например, справочник групп товаров. Измените через интерфейс наименование, добавьте новое, удалите его. Смотрите какие запросы возникают, какие триггеры отрабатывают (возможно, но маловероятно вызываются хранимые процедуры - проанализируйте и их вызовы) - таким образом выделите в схеме СУБД таблицы справочники и назначение их полей.
  • 6. Далее приступайте ко сложным объектом. Схема та же (но результат может быть отражен на большем количестве объектов СУБД) - выполняете основные действия (например, добавить товары в корзину и т.п.) -> ловите возникающие с ними действия к СУБД (команды, вызов процедур и т.п.) -> отслеживаете изменения СУБД -> документируете объекты и их составляющие (например, таблицы и их поля)
  • 7. Попробуйте выполнить отчеты через интерфейс (если есть). Анализируйте команды к СУБД для их построения аналогично шагам 6-7.
  • 8. Надеюсь к этому шагу часть вопросов по схеме СУБД снимется.
  • 9. Очень рекомендую во время наименьшей нагрузки периодически (например, раз в сутки в полночь) делать копию боевой СУБД и разворачивать ее на тестовой для дальнейшего изучения и экспериментов.

P.S. При анализе используйте названия таблиц и полей на предмет повторяемости. Например, изучаете работу с клиентом и таблица имеет название User. Поищите среди всех таблиц те, которые имеют поле User и анализируйте их назначение и т.п.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

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

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