Мне было интересно, насколько полезны внешние ключи в базе данных. По сути, если разработчики знают, с какими ключами зависят разные таблицы, они могут писать запросы так же, как если бы был внешний ключ, правильно?
Кроме того, я вижу, как ограничения внешнего ключа помогают предотвратить всевозможные ошибки с целостностью данных, но, скажем, например, программисты хорошо справляются с сохранением целостности данных, насколько необходимы внешние ключи?
Если вам не нужна референциальная целостность, вы правы. Но... вы должны заботиться о ссылочной целостности.
Проблема в том, что люди ошибаются. Компьютеры не делают.
Относительно вашего комментария:
но скажем, например, программисты хорошо справляются сохранение целостности данных
Кто-то в конце концов допустит ошибку. Никто не идеален. Также, если вы приносите кого-то нового в вас, вы не всегда уверены в своей способности писать "идеальный" код.
В дополнение к этому вы теряете возможность делать каскадные удаления и ряд других функций, которые позволяют определять внешние ключи.
Я думаю, что если предположить, что программисты всегда будут сохранять целостность данных, это опасное предположение.
Нет причин, по которым вы не будете создавать внешние ключи, а возможность гарантировать целостность вместо того, чтобы просто надеяться на целостность, является достаточной причиной.
Внешние ключи бесценны как средство обеспечения целостности, и даже если вы доверяете своим разработчикам, чтобы никогда (!) не делал ошибок, стоимость их наличия обычно стоит того.
Внешние ключи также служат документацией, так как вы можете видеть, что с ней связано. Эта информация обычно также используется инструментами, например, для создания отчетов, создания наборов данных из определений таблиц, объектно-реляционных картографов и т.д. Даже если вы не используете ни один из этих сегодня, наличие FK упростит прохождение этого пути позже.
Внешние ключи также позволяют определять каскадные правила, которые, например, может использоваться для удаления связанных записей в связанных таблицах при удалении строки в одной таблице.
Только если у вас смехотворно высокие нагрузки, вы должны рассмотреть возможность обхода FK.
Изменить: обновленный ответ, чтобы включить точки из других ответов (отчеты, каскады).
Не использовать ссылочную целостность в базе данных, как не использовать ремни безопасности в автомобилях. Это даст вам ощутимые улучшения в том, чтобы вы от A- > B, но это будет "реальная" разница только в самых крайних случаях. Зачем брать "риск", если вам действительно не нужно?
Подложная причина, по которой люди задают этот вопрос, всегда является производительностью.
Внешние ключи дают оптимизатору гораздо больше информации для работы, и это потенциально может привести к лучшим планам исполнения. Это не похоже на то, что конкретный запрос будет на% процентов быстрее с включенными ограничениями, это больше похоже на то, что вы эффективно устраняете целые классы проблем из-за неудачных планов выполнения. Вы также позволяете оптимизатору переписывать запросы способами, которые просто невозможны без ограничений (например, исключение объединения).
Начиная прямо здесь, я хотел бы начать миф о том, что ссылочная целостность всегда повышает производительность в базах данных. Я уверен, что если 100 человек разработали свои базы данных с полной проверкой целостности, менее 5 человек действительно должны будут потратить целую 1 секунду, чтобы отключить их по соображениям производительности. Из этих 5 человек будет около 0 человек, которые обнаруживают, что им необходимо отключить 100% ограничений.
Разместите слово;)
Вам не нужно их использовать, но почему бы и нет?
Они там, чтобы помочь. Чтобы облегчить жизнь с помощью каскадных обновлений и каскадных удалений, чтобы гарантировать, что ограничения не будут нарушены.
Возможно, приложение удовлетворяет ограничениям, но разве полезно ли их четко указывать? Вы можете документировать их, или вы можете поместить их в базу данных, где большинство программистов ожидают найти ограничения, которые они должны соответствовать (лучше, я думаю!).
Наконец, если вам когда-либо понадобится импортировать данные в эту базу данных, которые не проходят через интерфейс, вы можете случайно импортировать данные, которые нарушают ограничения и разрывают приложение.
Я бы определенно не рекомендовал пропустить отношения в базе данных
Вы сказали
но скажем, например, программисты делать хорошую работу по сохранению данных Целостность
Вы искали: "Я на 100% уверен, что каждый программист и каждый администратор базы данных будут вручную сохранять целостность данных независимо от того, какое приложение затрагивает эту базу данных, независимо от того, насколько сложна база данных, отныне время, когда оно списывалось".
Внешние ключи облегчают жизнь при использовании сборщиков отчетов и инструментов анализа данных. Просто выберите одну таблицу, установите флажок include related tables и БАМ!, у вас есть отчет, построенный. Хорошо. Хорошо, это не так просто, но они гарантируют сбережение времени в этом отношении.
Используйте ограничения, а не логику приложения, чтобы обеспечить целостность, потому что обычно проще, дешевле и надежнее поддерживать ограничения в одном месте (базе данных), а не в каждом приложении.
Я понимаю из одного из ваших комментариев, что ваша мотивация для постановки вопроса заключается в том, что вы считаете, что отказ от ключей может облегчить разработку дизайна базы данных во время разработки. По моему опыту вы ошибаетесь в этом. Я считаю, что на самом деле лучше быть более ограничительным с ограничениями на ранних этапах развития. Если есть сомнения, создайте ограничение, потому что гораздо легче удалить ограничения позже, чем создавать их. Удаление ограничения будет иметь тенденцию ломать меньше вещей, чем добавлять один, и обычно требуется меньшее тестирование и меньшее количество изменений кода для достижения.
Люди предложили несколько хороших ответов выше. Однако один важный момент, о котором я не упоминал, заключается в том, что внешние ключи упрощают создание диаграмм отношений сущностей (ERD) и значительно более значимые. Без FK вам либо нужно изображать отношения FK на вашей ERD вручную (болезненно для вас), либо совсем не так (больно для других и, возможно, даже для вас, как только ваша память о предполагаемых связях FK начинает исчезать со временем). Если явно определены FKs, большинство инструментов, которые автоматически генерируют ERD из определений объектов базы данных, автоматически обнаруживают и отображают отношения FK. Надеюсь, это поможет.
Еще один момент заключается в том, что, когда вы отказываетесь от своего текущего пользовательского интерфейса и используете новый с блестящими новыми инструментами, вы не потеряете свою ссылочную целостность, потому что новые разработчики не знают, что должно быть связано с чем. Базы данных, как правило, используются намного дольше, чем пользовательские интерфейсы. Они также часто используются более чем одним интерфейсом приложения, а затем у вас возникает проблема с различными интерфейсами, которые пытаются обеспечить соблюдение различных правил целостности.
Я также укажу, что мне приходилось смотреть на данные, в буквальном смысле, на сотни баз данных и еще не нашли одного, у которого есть хорошие данные, если они не настроили FK. Эти плохие данные усложняют отчетность, затрудняют импорт и экспорт клиентов и других сторонних поставщиков, которые нуждаются или предоставляют данные. И если плохие данные находятся в финансовой области, это может также иметь юридические и бухгалтерские последствия. Я могу даже помнить, что в один раз у компании были тысячи записей о плохих запасах, где фактический продукт, который был сохранен, больше не был идентифицируемым (или местным), что также создавало проблемы с определением ценности инвентаря, необходимого для финансовой отчетности. Это не только плохо с точки зрения того, что вы не знаете, какие части у вас есть, но это позволяет людям украсть детали, не будучи пойманными просто, удалив номер детали из таблицы деталей (в этом конкретном месте не было аудита на месте либо.).
Возможно, вопрос должен быть "Насколько плохи сиротские записи?". Во многих случаях сиротские записи на самом деле ничего не повредят. Да, эти записи могут сохраняться до конца времен, но насколько это плохо? Каскадные обновления или удаления редко являются полезными функциями. Ссылочная целостность звучит неплохо, но я думаю, что это не так важно, как нам верили. Самое большое преимущество FK - документация, которую они предоставляют. По моему опыту FK для ссылочной целостности - это больше проблем, чем они стоят.