отношения с базой данных

Question

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

ли они улучшают или препятствуют работе?

Answer 1

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

Их присутствие не мешает производительности, кроме как с точки зрения архитектуры (как указывали другие, целостность данных будет иногда вызывать нарушения внешнего ключа, которые могут иметь некоторый эффект), но IMHO перевешивается многими преимуществами (если используется правильно) ,

Я знаю, что вы не спрашивали, нужно ли использовать FKs или нет, но я думал, что просто добавить пару точек зрения о том, почему их использовать (и иметь дело с последствиями):

Там другие соображения тоже, например, если вы когда-либо планируете использовать ORM (возможно, позже), вам потребуются внешние ключи. Они также могут быть очень полезны для ETL/импорта данных и экспорта, а затем для отчетности и хранения данных.

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

Наконец, это дает довольно приличный намек относительно того, куда помещать индексы - так как вы, вероятно, будете искать данные таблицы по значению FK.

Answer 2

Связаны ли отношения в базах данных или ухудшают производительность?

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

Answer 3

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

Answer 4

Это ни то, ни другое не помогает и не ухудшает производительность. Единственное препятствие - проверка целостности при вставке/обновлении/удалении.

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

Answer 5

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

Краткое описание MS SQL Server можно найти по адресу http://www.microsoft.com/technet/abouttn/flash/tips/tips_122104.mspx. Я не знаю о других двигателях, но концепция будет иметь смысл на других платформах.

Answer 6

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

Объявление каскадных удалений через отношения помогает предотвратить некоторые виды ошибок при удалении данных.

Знание связей помогает гибко и правильно использовать данные при формировании запросов.

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

Answer 7

О влиянии на производительность: по моему опыту с MS Access 2003, если у вас многопользовательское приложение и используйте отношения для обеспечения значительного количества ссылочной целостности, вы можете получить большой успех с точки зрения времени ответа на конец -user.

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

Answer 8

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

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