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

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

 построение диаграммы со связями с рабочей базы - самый действенный вариант.  

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

затем все это дело распечатать и развесить на стенде/стене. 

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

 Составляем список чего не понимаем  

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

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

Подымаем контакты прошлых разработчиков, спрашиваем. 

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

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

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

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

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

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

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

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

  

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