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

Question

[Crash]

Допустим ситуация: мне нужно будет поддерживать крупный проект с БД с неясной структурой - большое количество таблиц (несколько десятков, а то и сотен), внешних ключей итд. Как максимально быстро и эффективно разобраться в ее структуре? Какие есть инструменты для визуализации связей между таблицами, независимо от их количества? Базы данных - MySQL и Postgres

Answer 1

[DevMan]

построение диаграммы со связями с рабочей базы - самый действенный вариант.
если таблиц много, сгруппировать их по возможности отдельными блоками.
затем все это дело распечатать и развесить на стенде/стене.

Answer 2

[Алексей Уколов]

MySQL Workbench позволяет построить диаграмму БД из готовой схемы.

Comments

[Crash]

да, пробовал. Но если таблиц реально очень много, то и разобраться тяжело даже по диаграмме. Может еще какие способы есть

Answer 3

[Александр N++]

Составляем список чего не понимаем
Задаем вопрос что база должна выполнять и как проект вообще должен работать.

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

Answer 4

[Владимир Чернышев]

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

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

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

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

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

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

5. Детализировать по мере необходимости, если анализ делается для себя. Сразу, если для внешнего потребления.

Answer 5

[Марат]

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

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