Отношения с базой данных
Помогает ли установка правильных отношений в базе данных с чем-то еще, кроме целостности данных?
они улучшают или мешают работе?
8 ответов
Я должен сказать, что правильные отношения помогут людям лучше понять данные (или их намерения), чем если бы они не были опущены, тем более что их общая стоимость довольно низкая.
Их присутствие не снижает производительность, кроме как с точки зрения архитектуры (как уже отмечали другие, целостность данных иногда вызывает нарушения внешнего ключа, что может иметь определенный эффект), но IMHO перевешивается многими преимуществами (при правильном использовании).
Я знаю, что вы не спрашивали, использовать ли FK или нет, но я подумал, что просто добавлю пару точек зрения о том, почему их использовать (и придется иметь дело с последствиями):
Есть и другие соображения, например, если вы когда-нибудь планируете использовать ORM (возможно, позже), вам потребуются внешние ключи. Они также могут быть очень полезны для ETL/ импорта и экспорта данных, а затем для отчетов и хранилищ данных.
Также полезно, если другие приложения будут использовать схему - поскольку внешние ключи реализуют базовую бизнес-логику. Таким образом, ваше приложение (и любые другие) должны знать только об отношениях (и уважать их). Это сохранит согласованность данных и, скорее всего, уменьшит количество ошибок данных в любых приложениях-потребителях.
И наконец, он дает вам довольно приличный совет относительно того, где размещать индексы - поскольку, скорее всего, вы будете искать данные таблицы по значению FK.
Пока у вас есть очевидные индексы, соответствующие внешним ключам, заметного негативного влияния на производительность не должно быть. Это одна из наиболее надежных функций базы данных, с которыми вам приходится работать.
Это ни помогает, ни ухудшает производительность. Единственным препятствием является проверка целостности при вставке / обновлении / удалении.
Внешние ключи являются важной частью проектирования базы данных, поскольку они обеспечивают согласованность. Вы должны использовать их, потому что они предлагают самый низкий уровень защиты от взлома данных, который может разрушить ваши приложения. Другое преимущество заключается в том, что инструменты базы данных (визуализация / анализ / генерация кода) используют внешние ключи для связи данных.
В моем опыте создания баз данных, чувствительных к производительности, внешние ключи значительно снижают производительность, так как их нужно проверять каждый раз, когда ссылающаяся запись вставляется / обновляется или основная запись удаляется. Если вам нужны доказательства, просто посмотрите на план выполнения.
Я до сих пор храню их для документации и инструментов, но обычно их отключаю, особенно в высокопроизводительных системах, где доступ к БД осуществляется только через прикладной уровень.
В зависимости от вашего механизма базы данных отношения, определенные через ограничения внешнего ключа, могут повысить производительность. Ограничение позволяет движку делать определенные предположения о существовании данных в таблицах на родительской стороне ключа.
Краткое объяснение MS SQL Server можно найти по адресу http://www.microsoft.com/technet/abouttn/flash/tips/tips_122104.mspx. Я не знаю о других движках, но концепция будет иметь смысл на других платформах.
Улучшают ли отношения в базах данных или снижают производительность?
Как и любой инструмент в вашем наборе инструментов, результаты, которые вы получите, зависят от того, как вы его используете. Правильно заданные отношения и хорошо спроектированная логическая база данных могут быть огромным благом для производительности - например, рассмотрим разницу между поиском по нормализованным и денормализованным данным.
Отношения в данных существуют независимо от того, объявляете ли вы их или нет. Объявление и обеспечение взаимосвязей посредством ограничений FK предотвратит определенные виды ошибок в данных при небольшой стоимости проверки данных при вставках / обновлениях / удалениях.
Объявление каскадного удаления через отношения помогает предотвратить определенные виды ошибок при удалении данных.
Знание отношений помогает гибко и правильно использовать данные при формировании запросов.
Правильная разработка таблиц может сделать отношения более очевидными и более полезными. Использование отношений в данных является основной силой, стоящей за использованием реляционных баз данных в первую очередь.
О влиянии на производительность. По моему опыту работы с MS Access 2003, если у вас есть многопользовательское приложение и вы используете Relationships для обеспечения большей ссылочной целостности, вы можете сильно пострадать с точки зрения времени отклика для конечного пользователя.
Существуют разные способы обеспечения ссылочной целостности. Я решил взять некоторые правила в отношениях, встроить больше правоприменения в интерфейс и жить с некоторой потерей RI. Конечно, в многопользовательской среде вы должны быть очень осторожны с этим кусочком свободы.