Это не будет легко.
Начните с сбора любой существующей документации, заметок и т. Д. Кроме того, это очень поможет получить полное представление о типе хранимых данных и о приложении. Сохраняйте достаточное количество записей о своих открытиях и соберите документацию, которую должен был построен ранее.
Если ваша база данных содержит объявленные внешние ключи, вы можете начать с нее и, по крайней мере, разорвать отношения между таблицами. Помните, что это может быть неполным. Как указывает @Джон Уотсон, если отношения объявляются, для этого есть инструменты.
Проверка сохраненных функций и процедур, включая триггеры. Хотя это несколько необычно в базах данных MySQL. Триггеры особенно часто дают подсказки («каждое обновление таблицы X вставляет новую строку в таблицу Y» -> «таблица Y, вероятно, является журналом или таблицей аудита»).
Надеемся, что некоторые таблицы очевидны, и, если вы знаете, что с ними связано, вы сможете приступить к выяснению этих связанных таблиц.
Надеюсь, у вас есть доступ к коду приложения, который вы можете найти и прочитать, чтобы найти подсказки. Также будет полезен доступ к тестовой среде, которую вы можете неоднократно уничтожать («что произойдет, если я изменю это в приложении, где изменится база данных?»; «Что произойдет, если я закодирую эти значения?» И т. Д.). Вы можете создавать дампы таблиц и использовать на них diff при условии, что вы создаете дампы по первичному или уникальному ключу.
Выполнение запросов, таких как SELECT DISTINCT foo FROM table, может помочь вам увидеть, что могут быть разные вещи в столбце.
Если возможно начать с практически пустой базы данных (например, минимальной для запуска приложения), вы можете наблюдать за изменениями при добавлении данных в приложение. Гораздо быстрее, чтобы сбросить базу данных, когда она мала. То же самое для сравнения, то же самое для чтения через вывод. Некоторые вещи легче понять в крошечной базе данных, но некоторые вещи сложнее. Когда у вас огромный набор данных и столбец всегда равен 3, вы можете быть намного увереннее в этом.
Вы можете наблюдать за трафиком SQL из приложений, чтобы получить представление о том, к каким таблицам и столбцам они получают доступ для каждой функции и как они присоединяются к ним. Наблюдение за трафиком SQL может быть выполнено в зависимости от приложения (например, трассировка DBI) или в зависимости от сервера (включите общий журнал запросов) или с помощью трассировщика пакетов, такого как Wireshark или tcpdump. Это будет зависеть от среды, в которой вы работаете. Например, если вам нужно сделать это в производственной системе, вам, вероятно, нужен Wireshark. Если вы делаете это в dev / test, недостаток журнала запросов MySQL заключается в том, что все приложения могут очень хорошо смешиваться друг с другом, и, если несколько пользователей попадут в приложения, это может привести к путанице. Журнал для приложения, вероятно, не пострадает от этого, но, конечно, приложение может не иметь этого.
Имейте в виду различные способы хранения данных. Например, все три из них могут означать 1 мая 1980 года:
- 1980-05-01 - как дата, время или текст.
- 2444330.5 - Юлианский день (со временем, указывает в полночь)
- 44360 - Модифицированный юлианский день
- 326001600 - Отметка времени UNIX (со временем указывает полночь) при условии, что местное время - это восточное время США (секунды с 1 января 1970 года по Гринвичу)
В базе данных могут быть денормализованные вещи, а некоторые из них могут быть ненормализованы неправильно. Например, вы можете задаться вопросом "почему у этого пользователя имя Боб в одной таблице и имя Джо в другой?" и ответ «повреждение данных».
Могут быть столбцы, которые не используются. Могут быть целые таблицы, которые не используются. Несмотря на это, у них все еще могут быть данные из более старых версий приложения (или других приложений, которые больше не используются), запросы запускаются из консоли MySQL и т. Д.
ThЭто могут быть вещи, которые нигде не видны в приложении, но используются.Их назначение может быть совершенно неочевидным без знания алгоритмов, реализованных в приложениях.Например, функция поиска в приложении может хранить все виды предварительно вычисленной информации о документах для поиска и их соединениях.Хуже того, эти таблицы могут обновляться только пакетными заданиями, поэтому изменение документа не коснется их (заставляя вас ошибочно полагать, что они не имеют ничего общего с документами).Затем вы приходите на следующее утро, и стол загадочным образом сильно отличается.Хотя, в случае поиска, журнал запросов при запуске поиска скажет вам.