Плохие схемы баз данных реального мира

Наш магистерский тезисный проект создает анализатор схемы базы данных. В качестве основы для этого мы работаем над количественной оценкой плохой структуры базы данных.

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

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

Мы уже запланировали следующие схемы анализа: wikimedia, moodle и drupal. Не уверен, в какой категории они подходят. Нет необходимости, чтобы схема была с открытым исходным кодом.

Используемый механизм базы данных не важен, хотя мы хотели бы сосредоточиться на SQL-сервере, Posgresql и Oracle.

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

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

Ответ 1

Я работаю над проектом, включая географическую информационную систему. И, на мой взгляд, эти проекты часто "средние" и "редкие".

Вот несколько примеров:

1) Geonames.org

Здесь вы можете найти данные и схему: http://download.geonames.org/export/dump/ (прокрутите вниз до нижней части страницы для схемы, это в тексте на сайте!)

Было бы интересно, как этот проект БД работает с таким ОГРОМНЫМ количеством данных!

2) OpenGeoDB

Этот очень популярен в немецкоязычных странах (Германия, Австрия, Швейцария), потому что это база данных, содержащая почти каждый город/город/деревню в немецкоязычном регионе с zip-кодом, именем, иерархией и координатами.

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

http://fa-technik.adfc.de/code/opengeodb/

Интересным в обоих примерах является то, как они управляли иерархией объектов, таких как Country → State → County → City → Village и т.д.

PS: Возможно, вы могли бы судить о моем дизайне БД тоже;) Схема базы данных управления доступом на основе ролей

Ответ 2

Проверьте Dell-dvd-store, вы можете использовать его бесплатно.

Dell DVD Store является открытым исходным кодом моделирование онлайн-сайта электронной коммерции с реализациями в Microsoft SQL Сервер, Oracle и MySQL вместе с драйверов и веб-приложений

Билл Карвин написал замечательную книгу о плохих проектах: SQL antipatterns

Ответ 3

vBulletin имеет очень плохую схему базы данных.

Ответ 4

"мы работаем над количественной оценкой плохой конструкции базы данных.

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

Я предлагаю вам подумать над следующим:

Может ли физическая схема быть "плохим", в то время как логическая схема тем не менее "чрезвычайно хороша"? Вы намерены правильно различать "логическую схему" и "физическую схему"? Как вы мечтаете достичь этого?

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

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

Ответ 5

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

Вот несколько идей, которые приходят на ум:

Я работаю в компании, которая занимается управлением базами данных для нескольких крупных розничных компаний. У нас есть настраиваемые базы данных, предназначенные для каждой из этих компаний, в соответствии с тем, как они намерены использовать данные (для прямой почтовой рассылки, кампаний по электронной почте и т.д.) И какие параметры анализа и выбора они предпочитают использовать. Например, компания, которая продает музыкальное оборудование в магазинах и в Интернете, хочет различать между посетителями и онлайн-клиентами, классифицирует клиентов в зависимости от типа предметов, которые они покупают (барабаны, гитары, микрофоны, клавиатуры, записывающее оборудование, усилители, и т.д.), и отслеживать, сколько они потратили и что они купили, за последние 6 месяцев или в прошлом году. Они используют эту информацию для определения того, кто будет получать каталоги по почте. Эти рассылки очень дороги; возможно, один или два доллара на одного клиента, поэтому компания хочет отправлять каталоги только тем, кто, скорее всего, что-то купит. У них может быть 15 миллионов клиентов в своей базе данных, но только 3 миллиона покупают барабаны, и только 750 000 купили что-либо в прошлом году.

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

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

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

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

Хорошо, на данный момент я из идей. Удачи вам в вашем проекте.

Ответ 6

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