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

Question

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

Здесь ' Физические отношения ' относятся к Первичный ключ , Внешний ключ , Проверка ограничений и т. Д.

При проектировании базы данных люди пытаются нормализовать базу данных на бумаге и документировать вещи. Мол, если мне нужно будет создать базу данных для маркетинговой компании, я постараюсь понять ее требования. Например, какие поля являются обязательными, какие поля будут содержать только (a или b или c) и т. Д.

Когда все ясно, тогда почему большинство людей боятся ограничений?

1. Разве они не хотят управлять вещами?
2. Есть ли у них недостаток знаний (что я так не думаю)?
3. Они не уверены в будущем проблемы?
4. Действительно ли сложно управлять всеми этими сущностями?

В чем причина, по вашему мнению?

Answer 1

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

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

Почему другие люди не используют ограничения PK и FK и т. Д.?

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

Answer 2

Многие разработчики проверяют ограничения в коде над базой данных, прежде чем они действительно перейдут к выполнению операции. Иногда это обусловлено соображениями взаимодействия с пользователем (мы не хотим представлять варианты / опции пользователям, которые не могут быть сохранены в базе данных). В других случаях это может быть вызвано болью, связанной с выполнением оператора, определением причины его неудачи и принятием корректирующих действий. Большинство людей посчитали бы, что код более удобен в обслуживании, если бы он выполнял проверку заранее, наряду с другой бизнес-логикой, которая могла бы быть задействована, вместо того, чтобы предпринимать корректирующие действия через обработчик исключений. (Не то чтобы это обязательно идеальная линия мышления, но она распространена.) В любом случае, если вы делаете проверку до выдачи заявления, и не особенно осознаёте тот факт, что база данных может быть затронута приложения / пользователи, которые не обращаются к вашему коду, обеспечивающему целостность, могут прийти к выводу, что ограничения базы данных не нужны, особенно с учетом снижения производительности, которое может возникнуть в результате их использования. Кроме того, если вы проверяете целостность в коде приложения над базой данных, можно считать это нарушением DRY (не повторять себя) для реализации логически эквивалентных проверок в самой базе данных. Два проявления правил целостности (ограничения в базе данных и правила в коде приложения над базой данных) могут в принципе стать несинхронными, если не будут тщательно управляться.

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

Answer 3

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

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

Совершенно безрассудно не формально устанавливать отношения PK / FK.Я обрабатываю данные, полученные от разных поставщиков и баз данных.Вы можете сказать, какие из них имеют проблемы с целостностью данных, скорее всего, вызванные невозможностью явно определить отношения из-за низкого качества их данных.

Answer 4

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

Answer 5

Существует несколько причин для неисполнения отношений в порядке убывания важности:

1. Удобная обработка ошибок.Ваша программа должна проверить ограничения и отправить понятное сообщение пользователю.По некоторым причинам обычным людям не нравится «Код исключения SQL -100013, нарушенный правилом гоблирования для таблицы gook».

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

3. Эффективность. Ограничения проверки действительно требуют ввода-выводаи ЦП.

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

Answer 6

Ну, я имею в виду, каждый имеет право на собственное мнение и стратегию развития, я полагаю, но, по моему скромному мнению, эти люди почти наверняка ошибаются:)

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

Что касается мотивации не использовать FK без мотивации кеширования, я не могу себе этого представить. Возможно, они стремятся быть «гибкими» в своей структуре БД. Если так, хорошо, но тогда не используйте реляционную БД, потому что это бессмысленно. Нереляционная БД (OO DBS), безусловно, имеет место, и, возможно, даже, возможно, будет лучше (довольно спорен, но интересно поспорить), но это ошибка использовать реляционную БД, а не использовать его основные свойства.