Вам абсолютно необходимы внешние ключи в базе данных? - PullRequest
17 голосов
/ 31 марта 2011

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

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

Ответы [ 11 ]

24 голосов
/ 31 марта 2011

Если вас не волнует ссылочная целостность, тогда вы правы. Но .... вы должны заботиться о ссылочной целостности.

Проблема в том, что люди делают ошибки. Компьютеры нет.

По поводу вашего комментария:

но скажем, например, программисты делают хорошую работу сохранение целостности данных

Кто-то в конце концов совершит ошибку. Никто не идеален. Кроме того, если вы привносите кого-то нового, вы не всегда уверены в его способности писать «идеальный» код.

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

9 голосов
/ 31 марта 2011

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

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

6 голосов
/ 01 апреля 2011

Вы сказали

но скажем, например, программисты сделать хорошую работу по сохранению данных Целостность

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

6 голосов
/ 31 марта 2011

Не использовать ссылочную целостность в базе данных, все равно что не использовать ремни безопасности в автомобилях. Это обеспечит вам ощутимые улучшения в отводе вас от A-> B, но будет иметь «реальную» разницу только в самых крайних случаях. Зачем рисковать, если вам действительно не нужно?

Основная причина, по которой люди задают этот вопрос, - это всегда производительность.

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

С этого момента я хотел бы начать миф о том, что ссылочная целостность всегда повышает производительность в базах данных. Я вполне уверен, что если 100 человек спроектировали свои базы данных с полной проверкой целостности, менее 5 человек фактически должны были бы потратить целую 1 секунду, чтобы отключить их по соображениям производительности. Из этих 5 человек будет около 0 человек, которые обнаружат, что им необходимо отключить 100% ограничений.

Распространите слово;)

6 голосов
/ 31 марта 2011

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

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

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

Только при наличиисмехотворно высокие нагрузки, если вы подумаете об обходе FK.

Редактировать: обновленный ответ для включения точек из других ответов (отчеты, каскады).

5 голосов
/ 31 марта 2011

Вам не нужно их использовать, но почему бы и нет?

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

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

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

Я бы определенно не рекомендовал пропускать отношения в базе данных

3 голосов
/ 31 марта 2011

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

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

3 голосов
/ 31 марта 2011

Внешние ключи значительно упрощают жизнь при использовании построителей отчетов и инструментов анализа данных. Просто выберите одну таблицу, установите флажок include related tables и BAM! , у вас есть отчет. Хорошо, хорошо, это не так просто, но они определенно экономят время в этом отношении.

2 голосов
/ 23 сентября 2015

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

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

2 голосов
/ 01 апреля 2011

Люди предложили несколько хороших ответов выше. Тем не менее, один важный момент, о котором я не упомянул, заключается в том, что внешние ключи упрощают создание ваших диаграмм отношений сущностей (ERD) и делают их более значимыми. Без ФК вам либо нужно изобразить отношения ФК в вашем ERD вручную (болезненно для вас), либо не показывать совсем (больно другим, и, возможно, даже вам самим, как только ваша память о подразумеваемых отношениях ФК со временем начинает угасать). С явно определенными FK большинство инструментов, которые автоматически генерируют ERD из определений объектов базы данных, автоматически обнаруживают и отображают отношения FK. Надеюсь, это поможет.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...