Как погрузиться в некрасивую базу данных?

Я уверен, что многие из вас имеют дело с ужасной базой данных. Вы знаете, та база данных, которая вообще не нормализована, та база данных, где вы должны выполнить большой болезненный запрос, чтобы получить самые тривиальные данные, та база данных, которая находится в работе, и вы не можете ничего изменить ... вы знаете, , "вон тот".

Мой вопрос, как вы справляетесь с этим?

• Вы пытаетесь создать новую базу данных?
• Ты сдаешься и оставляешь это в покое?
• Какой совет вы можете дать?

• Первое, что я делаю, это создаю диаграмму сущности-отношения (ERD). Иногда вы можете просто описать метаданные с помощью инструментов командной строки, но для экономии времени есть некоторые инструменты, которые могут генерировать диаграмму автоматически.

• Во-вторых, изучите каждую таблицу и столбец, чтобы убедиться, что я понял значение того, что она хранит.

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

• В-четвертых, прочитайте любые представления или триггеры, чтобы понять, как настраивать целостность данных или каскадные операции.

• В-пятых, прочитайте любые хранимые процедуры. Также прочитайте привилегии доступа SQL, если они есть.

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

Обновление: я только что прочитал интересную статью " 9 вещей, которые нужно делать, когда вы наследуете базу данных " с хорошим контрольным списком.

Резюме:

1. Резервные копии
2. Исследования (этапы документирования схемы, о которых я упоминал выше)
3. Поговорите с бывшими разработчиками
4. База данных ошибок
5. Контроль исходного кода
6. Поговорите с пользователями и / или владельцами бизнеса
7. Заведите доверие к пользователям, исправив несколько вещей или сделав некоторые улучшения
8. Создать среду разработки
9. Отбросьте устаревшие объекты

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

Словарь данных - ваш друг. Кроме того, попробуйте выполнить обратный инжиниринг базы данных с помощью инструмента обратного инжиниринга в Visio и создайте свой собственный набор диаграмм. Поскольку обратный инжиниринг интерактивен - вы строите диаграммы - это гораздо более увлекательно, чем чтение словаря данных. Активность процесса является его преимуществом, и я нахожу это довольно расслабляющим, чтобы сделать это.

Большая часть работы, которую я выполняю, связана с хранилищем данных, где изучение схем базы данных исходной системы является одним из основных видов деятельности. Я делал подобные вещи довольно много раз и обнаружил, что это действительно хорошо работает.

Visio pro не так уж и дорог, и механизм моделирования Visio позволяет разделить модель между несколькими диаграммами. В качестве бонуса вы можете добавить недостающие внешние ключи на диаграммах и получить полезный комплект документации для системы.

В дополнение к идеям Билла Карвина я предлагаю поговорить с пользователями - иногда пользователи довольно много знают о том, для чего используется их база данных, особенно если они делают какие-либо отчеты из нее.

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

Одна из вещей, которую я быстро начал использовать, поскольку база данных не имеет абсолютно никаких отношений, это общий запрос Name для схемы:

--Find Column named like 'blah' in a specific table
SELECT O.NAME, O.ID, C.NAME, O.XTYPE
FROM SYSOBJECTS O LEFT JOIN SYSCOLUMNS C ON O.ID=C.ID
WHERE C.NAME LIKE '%SearchFor%' AND O.XTYPE IN ('U','V') AND O.Name like '%TableName%'
ORDER by O.Name

или

--Find all Columns in DB with name like 'blah'    
SELECT O.NAME, O.ID, C.NAME, O.XTYPE
FROM SYSOBJECTS O LEFT JOIN SYSCOLUMNS C ON O.ID=C.ID
WHERE C.NAME LIKE '%SearchFor%' AND O.XTYPE IN ('U','V')
ORDER by O.Name

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

Я знаю, что это мало помогает в части вопроса о редизайне, но очень помогает в понимании и расшифровке плохой схемы.

SchemaCrawler - это мой инструмент для обнаружения баз данных, в котором есть несколько функций, облегчающих исследование уродливой базы данных. SchemaCrawler имеет «grep» -подобную функциональность, которая позволяет вам искать таблицы и столбцы с помощью регулярных выражений. Например, вы можете искать таблицы и столбцы с «ACCOUNT» как частью их имени, и они, вероятно, будут каким-то образом связаны.

SchemaCrawler также выводит отношения внешних ключей, даже если внешних ключей нет. Это достигается путем нахождения «слабых ассоциаций» с использованием общих соглашений об именах, например, имена таблиц обычно являются множественными, а имена столбцов - нет, а имена столбцов могут иметь префикс _ID. Вы можете найти связанные таблицы, используя эти предполагаемые отношения.

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

Данные сотрудника

Есть база данных, в которой хранятся данные сотрудников. Это база данных поставщиков, поэтому я не могу ее контролировать. (Un?) К счастью, у меня нет прямого доступа к нему. Я получаю дтс-дамп каждое утро.

Лучшее, чем я смог управлять, - это написать скрипт, который очищает ввод от утреннего дампа (да, выбор слова был преднамеренным) и переносить его в более полезный формат, а также работать с очищенными данными.

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

Данные онлайн-обучения

Это был беспорядок моего собственного дизайна. Я построил это недавно из колледжа без наставника, чтобы помочь мне ... Я с тех пор исправлял это немного за один раз. Поскольку я контролирую единственную программу, которая обращается к данным, при обновлении частей сайта я буду «обновлять» конфигурацию базы данных. Я напишу сценарий преобразования и энергично протестирую его на копии, чтобы убедиться, что все необходимые изменения должны быть внесены.

Это был долгий процесс, но все идет хорошо.

Данные обучения в классе

Мой пилотный проект включал в себя данные из 3 разных баз данных, все разработанные немного по-разному моим предшественником ... который был педагогом-медсестрой, который брал урок программирования или два.

Это был еще один медленный процесс. Поскольку я полностью контролирую программы, которые обращаются к данным, я постепенно меняю их, как данные онлайн-обучения.

Оглядываясь назад, это было бы главным кандидатом на то, чтобы начать чистоту ... задний план всегда 20/20.

В конце...

Я не знаю, насколько это было полезно, и я могу подробнее рассказать (в частности, о юридической компании и т. Д.). Окончательный ответ: «Это зависит».

Итак, прочитав все ваши ответы, я дам вам свой:

Сначала я ищу «Основную таблицу», затем пером и бумагой начинаю отображать отношения с другими таблицами, после этого, если есть какой-то код приложения, на который я обращаю внимание, я начинаю делать несколько сырых набросков о том, как данные передаются.

После того, как я получил хорошую картину того, как работает база данных, я просто начал проверять места, где можно что-то изменить Вот и все.

Я не знаю почему, но я предпочитаю бумагу любому программному обеспечению для моделирования баз данных.

Из-за использования его внешним приложением вы не можете изменить «интерфейс» базы данных. Я не знаю, какую базу данных вы используете (oracle, mysql, mssql), но я вижу это как один из способов:

• построение интерфейса базы данных с использованием таких типов объектов, как представление и хранимые процедуры.
• пошаговый рефакторинг (нормализация, переименование полей ...)
• изменение заявки клиента (если требуется)

Представления, хранимые процедуры будут скрывать внутренние изменения (изменения) баз данных.

В дополнение к раскрытию структуры базы данных я обнаружил, что важно также учитывать качество данных . Как только вы поймете значение каждого столбца, вы сможете искать любые места, где много пропущенных значений. По мере знакомства с данными вы также можете проверить, есть ли несоответствия между значениями в разных столбцах.

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

Если вы можете разделить проблему на проблемы, которые вы можете обернуть вокруг себя, вы можете атаковать их по одному. Иногда, просто зная, что есть одна таблица, которая не все глючит, можно получить плацдарм для работы. Таким образом, вы расширяете свое «чистое место», чтобы охватить больше базы данных кусками.

Если у вас есть Visio (часть Microsoft Office), вы можете попробовать функцию обратного инженера . Это не красиво, но это, по крайней мере, даст вам старт (за долю от стоимости «настоящих» инструментов, таких как Rational Rose).

Schema Spy - действительно хороший инструмент для генерации ERD.

Билл дал отличный ответ. Я хотел бы добавить, что я войду в пользовательский интерфейс в качестве тестового пользователя и попытаюсь точно понять, что пользователи делают с данными. Это поможет вам понять причину некоторых сохраненных процедур или дизайна. Понимание того, что означают и для чего используются данные, имеет решающее значение для понимания базы данных.

Если база данных относится к бизнес-функции или предмету, с которым вы в целом незнакомы (скажем, она занимается планированием полетов, а ранее вы работали только с финансовыми приложениями), то попросите пользователей предоставить материалы для чтения по данной теме или посетите библиотеку. самостоятельно или поищите в интернете предмет. Спросите пользователей, существуют ли какие-либо правовые или нормативные вопросы, о которых вам необходимо знать. Опять же, некоторые из этого предметного фона могут объяснить то, что кажется странным выбором дизайна.

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

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

По моему опыту создание новой базы данных на самом деле не вариант, так как перемещение сотен ГБ или ТБ данных не так уж и осуществимо.

Оставить это в покое также обычно не вариант. По мере того, как объем данных в базе данных растет, производительность становится все хуже и хуже (к тому времени, когда я вижу проблемы, они обычно чертовски плохи). В конечном итоге пользователи не смогут использовать приложение, потому что производительность очень низкая.

Ах ... Уродливая база данных. Чем крупнее предприятие, тем больше устаревших баз данных мы найдем.

• При настройке производительности люди не жалуются на такие базы данных, пока не обнаружат проблемы с производительностью. Поэтому в нашей организации мы идентифицируем отдельные запросы и настраиваем их как патч.
• Ограничивая данные, теперь мы знаем, где вонючий мусор, поэтому постарайтесь избегать потока данных через такие базы данных. Создайте промежуточные базы данных и перенаправьте данные в эти таблицы, чтобы начать и использовать старые в качестве дампов данных.
• Избегайте накопления данных. Архивируйте / обрезайте старые данные, которые больше не требуются. Должна быть команда, которая решает, как долго данные требуются в базе данных. После этого вы можете переместить его в плоские файлы или даже на ленточные накопители.
• Откажитесь от него, как только вы сможете добиться перенаправления и усечения данных. Убедите другие команды начать использовать новую базу данных.

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

Удачи с твоей уродливой подружкой;)

Посмотрите, доступен ли вам вариант сеанса передачи знаний, и если да, воспользуйтесь им в полной мере.

Кроме того, многие СУБД поставляются с инструментами, которые позволяют рисовать / распечатывать схему базы данных с некоторой полезной информацией (например, внешними ключами).

Кроме того, (украдено из NXC) вы можете перепроектировать базу данных с помощью таких инструментов, как Visio.

Мне нравится запускать профилировщик запросов и смотреть, что происходит в производственной системе. Дает мне некоторое представление о том, какие таблицы являются «горячими» и какие запросы к ним применяются.

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

Кроме того, мне нравится открывать The Daily WTF в окне браузера. Принятие чужого дизайна обычно включает в себя много моментов «я не могу поверить, что они сделали {WTF}», и это помогает найти место, где люди понимают вашу боль.