Насколько мне известно, внешние ключи (FK) используются, чтобы помочь программисту правильно манипулировать данными. Предположим, что программист уже делает это правильно, тогда действительно ли нам нужна концепция внешних ключей?
Есть ли другие способы использования внешних ключей? Я что-то упустил?
Внешние ключи помогают обеспечить ссылочную целостность на уровне данных. Они также улучшают производительность, поскольку обычно индексируются по умолчанию.
Внешние ключи также могут помочь программисту писать меньше кода, используя такие вещи, как ON DELETE CASCADE. Это означает, что если у вас есть одна таблица, содержащая пользователей, а другая - заказы или что-то в этом роде, то удаление пользователя может автоматически удалить все заказы, которые указывают на этого пользователя.
Я не могу представить себе создание базы данных без внешних ключей. Без них вы неизбежно совершите ошибку и нарушите целостность ваших данных.
Строго говоря, они не обязательны, но преимущества огромны.
Я почти уверен, что FogBugz не имеет ограничений внешнего ключа в базе данных. Мне было бы интересно услышать, как команда Fog Creek Software структурирует свой код, чтобы гарантировать, что они никогда не вносите несоответствия.
Схема базы данных без ограничений FK похожа на вождение без ремня безопасности.
Однажды ты пожалеешь об этом. Не тратить лишнее время на основы дизайна и целостность данных - верный способ избавиться от головной боли в будущем.
Вы бы приняли такой небрежный код в своем приложении? Это напрямую обращалось к объектам-членам и напрямую изменяло структуры данных.
Как вы думаете, почему это стало жестким и даже неприемлемым в современных языках?
да.
ON DELETE CASCADEПредположим, что программист уже делает это правильно.
Такое предположение кажется мне крайне плохой идеей; в общем софт феноменально глючный.
И в этом-то и дело. Разработчики не могут все сделать правильно, поэтому обеспечение того, чтобы база данных не была заполнена плохими данными, - это хорошо.
Хотя в идеальном мире естественные объединения будут использовать отношения (то есть ограничения FK), а не сопоставление имен столбцов. Это сделало бы FK еще более полезными.
Лично я сторонник внешних ключей, потому что они формализуют отношения между таблицами. Я понимаю, что ваш вопрос предполагает, что программист не вводит данные, которые нарушили бы ссылочную целостность, но я видел слишком много случаев, когда ссылочная целостность данных нарушалась, несмотря на самые лучшие намерения!
Ограничения до внешнего ключа (также известные как декларативная ссылочная целостность или DRI) много времени было потрачено на реализацию этих отношений с помощью триггеров. Тот факт, что мы можем формализовать отношения с помощью декларативного ограничения, очень важен.
@John - другие базы данных могут автоматически создавать индексы для внешних ключей, но SQL Server этого не делает. В SQL Server отношения внешнего ключа - это только ограничения. Вы должны определить свой индекс для внешних ключей отдельно (что может быть полезно).
Изменить: я хотел бы добавить, что, IMO, использование внешних ключей для поддержки ON DELETE или ON UPDATE CASCADE не обязательно хорошо. На практике я обнаружил, что каскад при удалении следует тщательно рассматривать на основе взаимосвязи данных - например, у вас есть естественный родитель-потомок, где это может быть нормально, или связанная таблица является набором значений поиска. Использование каскадных обновлений подразумевает, что вы разрешаете изменять первичный ключ одной таблицы. В этом случае у меня есть общие философские разногласия в том, что первичный ключ таблицы не должен изменяться. Ключи должны быть неизменными по своей сути.
Без внешнего ключа, как узнать, что две записи в разных таблицах связаны?
Я думаю, что вы имеете в виду ссылочную целостность, когда дочерняя запись не может быть создана без существующей родительской записи и т. Д. Это часто известно как ограничения внешнего ключа, но не следует путать с существованием внешних ключей в первое место.
Есть ли преимущество в отсутствии внешних ключей? Если вы не используете дрянную базу данных, FK не так уж и сложно настроить. Так почему бы вам избегать их? Одно дело иметь соглашение об именах, которое гласит, что столбец ссылается на другой, другое - знать, что база данных действительно проверяет эту связь за вас.
FK очень важны и всегда должны присутствовать в вашей схеме, , если вы не eBay.
unibrow 23.08.2013 Я полагаю, вы говорите об ограничениях внешнего ключа, налагаемых базой данных. Вы, вероятно, уже используете внешние ключи, вы просто не сообщили об этом базе данных.
Предположим, что программист уже делает это правильно, тогда действительно ли нам нужна концепция внешних ключей?
Теоретически нет. Однако никогда не было программного обеспечения без ошибок.
Ошибки в коде приложения обычно не так опасны - вы определяете ошибку и исправляете ее, и после этого приложение снова работает без сбоев. Но если ошибка позволяет обработанным данным попасть в базу данных, значит, вы застряли с ней! Восстановить поврежденные данные в базе данных очень сложно.
Подумайте, не позволила ли незаметная ошибка в FogBugz записать поврежденный внешний ключ в базу данных. Исправить ошибку и быстро отправить исправление клиентам в выпуске исправления может оказаться несложным. Однако как исправить поврежденные данные в десятках баз данных? Правильный код теперь может внезапно сломаться, потому что предположения о целостности внешних ключей больше не выполняются.
В веб-приложениях у вас обычно есть только одна программа, взаимодействующая с базой данных, поэтому есть только одно место, где ошибки могут повредить данные. В корпоративном приложении может быть несколько независимых приложений, обращающихся к одной и той же базе данных (не говоря уже о людях, работающих непосредственно с оболочкой базы данных). Невозможно быть уверенным, что все приложения всегда и навсегда следуют одним и тем же предположениям без ошибок.
Если ограничения закодированы в базе данных, худшее, что может случиться с ошибками, - это то, что пользователю будет показано уродливое сообщение об ошибке о некотором ограничение SQL не выполнено. Это намного предпочтительнее, чем разрешать сокращать данные в вашей корпоративной базе данных, где это, в свою очередь, нарушит работу всех ваших приложений или просто приведет к разного рода неправильным или вводящим в заблуждение результатам.
Да, и ограничения внешнего ключа также улучшают производительность, потому что они индексируются по умолчанию. Я не могу придумать причины не использовать ограничения внешнего ключа.
Я думаю, что какая-то вещь в какой-то момент должна отвечать за обеспечение нормальных отношений.
Например, Ruby on Rails не использует внешние ключи, но сам проверяет все взаимосвязи. Если вы когда-либо обращаетесь к своей базе данных только из этого приложения Ruby on Rails, это нормально.
Однако, если у вас есть другие клиенты, которые пишут в базу данных, то без внешних ключей им необходимо реализовать собственную проверку. Затем у вас есть две копии кода проверки, которые, скорее всего, отличаются, что любой программист должен уметь сказать, что это кардинальный грех.
На этом этапе действительно необходимы внешние ключи, поскольку они позволяют снова перенести ответственность на одну точку.
Внешние ключи позволяют тому, кто раньше не видел вашу базу данных, определить взаимосвязь между таблицами.
Сейчас все может быть хорошо, но подумайте, что будет, когда ваш программист уйдет, а его место займет кто-то другой.
Внешние ключи позволят им понять структуру базы данных, не просматривая тысячи строк кода.
Насколько мне известно, внешние ключи используются, чтобы помочь программисту правильно манипулировать данными.
FK позволяют администратору баз данных защищать целостность данных от неуклюжих действий пользователей, когда программист терпит неудачу, а иногда и для защиты от неуклюжих действий программистов.
Предположим, что программист уже делает это правильно, тогда действительно ли нам нужна концепция внешних ключей?
Программисты смертны и подвержены ошибкам. FK являются декларативными, поэтому их сложнее испортить.
Есть ли другие способы использования внешних ключей? Я что-то упустил?
Хотя они были созданы не для этого, FK обеспечивают надежные подсказки для инструментов построения диаграмм и построителей запросов. Это передается конечным пользователям, которым отчаянно нужны надежные подсказки.
Они не являются строго необходимыми, как и ремни безопасности не являются строго необходимыми. Но они действительно могут спасти вас от глупостей, которые могут испортить вашу базу данных.
Намного приятнее отладить ошибку ограничения FK, чем восстанавливать удаление, которое сломало ваше приложение.
Они важны, потому что ваше приложение - не единственный способ манипулировать данными в базе данных. Ваше приложение может обрабатывать ссылочную целостность так честно, как оно того хочет, но все, что для этого требуется, - это один бозо с нужными привилегиями, чтобы подойти и выдать команду вставки, удаления или обновления на уровне базы данных, и все ваше приложение может обойти ссылочную целостность. Включение ограничений FK на уровне базы данных означает, что, если этот бозо не выбирает отключение ограничения FK перед выдачей своей команды, ограничение FK приведет к сбою неправильного оператора вставки / обновления / удаления с нарушением ссылочной целостности.
Я думаю об этом с точки зрения затрат / выгод ... В MySQL добавление ограничения является одна дополнительная строка DDL. Это всего лишь несколько ключевых слов и пара секунд размышлений. На мой взгляд, это единственная «цена» ...
Инструменты любят внешние ключи. Внешние ключи предотвращают появление неверных данных (то есть потерянных строк), которые не могут повлиять на бизнес-логику или функциональность и, следовательно, остаются незамеченными и накапливаются. Это также не позволяет разработчикам, незнакомым со схемой, реализовывать целые фрагменты работы, не осознавая, что у них отсутствует взаимосвязь. Возможно, в рамках вашего текущего приложения все отлично, но если вы что-то пропустили, и когда-нибудь будет добавлено что-то неожиданное (подумайте о причудливой отчетности), вы можете оказаться в таком месте, где вам придется вручную очистить плохие данные, которые накапливались с момента создания. схемы без принудительной проверки базы данных.
Небольшое время, необходимое для систематизации того, что уже находится в вашей голове, когда вы собираете вещи, может спасти вас или кого-то еще от нескольких месяцев или лет горя.
Вопрос:
Есть ли другие способы использования внешних ключей? Я что-то упустил?
Немного загружено. Вставляйте комментарии, отступы или имена переменных вместо «внешних ключей» ... Если вы уже прекрасно понимаете предмет, о котором идет речь, вам это «бесполезно».
Снижение энтропии. Уменьшите вероятность возникновения хаотических сценариев в базе данных. У нас тяжелые времена, поскольку мы рассматриваем все возможности, поэтому, на мой взгляд, снижение энтропии является ключом к поддержанию любой системы.
Когда мы делаем предположение, например: у каждого заказа есть покупатель, это предположение должно подкрепляться чем-то. В базах данных этим «чем-то» являются внешние ключи.
Я думаю, что это стоит компромисса в скорости разработки. Конечно, вы можете быстрее писать код без них, и, вероятно, поэтому некоторые люди их не используют. Лично я убил несколько часов с помощью NHibernate и некоторого ограничения внешнего ключа, которое раздражает, когда я выполнить некоторую операцию. ОДНАКО, я знаю, в чем проблема, поэтому это не проблема. Я использую обычные инструменты, и есть ресурсы, которые помогут мне обойти эту проблему, возможно, даже люди, которые могут помочь!
Альтернативный вариант - позволить ошибке проникнуть в систему (и, если у вас будет достаточно времени, это произойдет), когда внешний ключ не установлен, и ваши данные станут несовместимыми. Затем вы получите необычный отчет об ошибке, исследуйте и «ОН». База данных прикручена. Теперь, сколько времени уйдет на то, чтобы это исправить?
Вы можете рассматривать внешние ключи как ограничение, которое,
В настоящее время мы не используем внешние ключи. И по большей части мы не жалеем об этом.
Тем не менее - мы, вероятно, начнем использовать их гораздо больше в ближайшем будущем по нескольким причинам, обе по схожим причинам:
Построение диаграмм. Гораздо проще создать диаграмму базы данных, если правильно используются отношения внешних ключей.
Поддержка инструмента. Намного проще создавать модели данных с помощью Visual Studio 2008, который можно использовать для LINQ to SQL, если есть правильные отношения внешнего ключа.
Итак, я полагаю, что моя точка зрения заключается в том, что мы обнаружили, что если мы делаем много ручной работы с SQL (создание запроса, выполнение запроса, бла-бла-бла), внешние ключи не обязательно необходимы. Однако как только вы начнете пользоваться инструментами, они станут намного полезнее.
Лучшее в ограничениях внешнего ключа (и вообще в ограничениях) заключается в том, что вы можете полагаться на них при написании запросов. Многие запросы могут стать намного сложнее, если вы не можете полагаться на то, что модель данных содержит «истину».
В коде мы обычно просто получаем исключение, но в SQL мы ' Я обычно получаю "неправильные" ответы.
Теоретически SQL Server может использовать ограничения как часть плана запроса, но за исключением проверочных ограничений. Что касается разделения, я не могу сказать, что когда-либо был свидетелем этого.
Внешние ключи никогда не были явными (таблица FOREIGN KEY REFERENCES (столбец)), объявленными в проектах (бизнес-приложения и веб-сайты социальных сетей), над которыми я работал.
Но всегда существовало некое соглашение об именах столбцов, которые были внешними ключами.
Это похоже на нормализацию базы данных - вы должны знать, что вы делаете и каковы последствия что (в основном производительность).
Я знаю о преимуществах внешних ключей (целостность данных, индекс для столбца внешнего ключа, инструменты, знающие схему базы данных), но также я боюсь использовать внешние ключи как общее правило.
Кроме того, различные механизмы базы данных могут по-разному обслуживать внешние ключи, что может привести к незначительным ошибкам во время миграции.
Удаление всех заказов и счетов-фактур удаленного клиента с помощью ON DELETE CASCADE - прекрасный пример красивой, но неправильно спроектированной схемы базы данных.
да. ON DELETE [RESTRICT | CASCADE] не позволяет разработчикам связывать данные, сохраняя их в чистоте. Недавно я присоединился к команде разработчиков Rails, которые не уделяли внимания ограничениям базы данных, таким как внешние ключи.
К счастью, я нашел это: http://www.redhillonrails.org/foreign_key_associations.html - - Плагины RedHill on Ruby on Rails генерируют внешние ключи, используя соглашение по стилю конфигурации. При миграции с product_id будет создан внешний ключ для id в таблице products.
Ознакомьтесь с другими замечательными надстройками на RedHill, включая миграции, заключенные в транзакции.
Если вы планируете генерировать свой код доступа к данным, то есть Entity Framework или любой другой ORM, вы полностью теряете возможность генерировать иерархическую модель без внешних ключей.
