Внешние ключи действительно необходимы в проектировании баз данных?
tl; dr
Панда, эквивалентная
select * from table where column_name = some_value
, является
table[table.column_name == some_value]
Множественные условия:
table[(table.column_name == some_value) | (table.column_name2 == some_value2)]
или
table.query('column_name == some_value | column_name2 == some_value2')
Пример кода
import pandas as pd
# Create data set
d = {'foo':[100, 111, 222],
'bar':[333, 444, 555]}
df = pd.DataFrame(d)
# Full dataframe:
df
# Shows:
# bar foo
# 0 333 100
# 1 444 111
# 2 555 222
# Output only the row(s) in df where foo is 222:
df[df.foo == 222]
# Shows:
# bar foo
# 2 555 222
В приведенном выше коде это строка df[df.foo == 222], которая дает строки на основе значения столбца, 222 в этом case.
Возможны также множественные условия:
df[(df.foo == 222) | (df.bar == 444)]
# bar foo
# 1 444 111
# 2 555 222
Но в этот момент я бы рекомендовал использовать функцию query , так как он менее подробный и дает тот же результат:
df.query('foo == 222 | bar == 444')
23 ответа
Внешние ключи помогают осуществить ссылочную целостность на уровне данных. Они также улучшают производительность, потому что они обычно индексируются по умолчанию.
Да. НА УДАЛЯЮТ [RESTRICT|CASCADE], мешает разработчикам скручивать данные, содержа данные в чистоте. Я недавно присоединился к команде разработчиков направляющих, которые не сфокусировались на ограничениях базы данных, таких как внешние ключи.
К счастью, я нашел их: http://www.redhillonrails.org/foreign_key_associations.html - Редхилл на плагинах Ruby on Rails генерируют внешние ключи с помощью соглашение по конфигурации стиль. Миграция с product_id создаст внешний ключ к идентификатор в эти продукты таблица.
Выезд другие большие плагины в Редхилл , включая миграции, обернутые в транзакции.
Внешние ключи никогда не были явными (таблица FOREIGN KEY REFERENCES (столбец)) объявленный в проектах (бизнес-приложения и социальные сети), который я продолжил работать.
, Но всегда было своего рода соглашением именования столбцов, которые были внешними ключами.
Это похоже с нормализация базы данных - необходимо знать то, что является Вами выполнение и что является последствием того (главным образом производительность).
я знаю о преимуществах внешних ключей (целостность данных, индекс для столбца внешнего ключа, инструменты, знающие о схеме базы данных), но также и я боюсь использования внешних ключей как общее правило.
Также различные механизмы базы данных могли служить внешним ключам по-другому, которые могли привести к тонким ошибкам во время миграции.
Удаление всех заказов и счетов удаленного клиента с НА УДАЛЯЕТ КАСКАД, идеальный пример хорошего взгляда, но неправильно разработанный, схема базы данных.
Лучшая вещь об ограничениях внешнего ключа (и ограничениях в целом, действительно) то, что можно полагаться на них при записи запросов. Много запросов может стать намного более сложным, если Вы не можете полагаться на модель данных, содержащую "верный".
В коде, мы будем обычно просто бросать исключение где-нибудь - но в SQL, мы будем обычно просто получать "неправильные" ответы.
В теории, SQL Сервер мог использовать ограничения в качестве части плана запросов - но за исключением проверочных ограничений для разделения, я не могу сказать, что когда-либо на самом деле свидетельствовал это.
Мы в настоящее время не используем внешние ключи. И по большей части мы не сожалеем о нем.
, Который сказал - мы, вероятно, начнем использовать их намного больше в ближайшем будущем по нескольким причинам, них обоих по подобным причинам:
-
Схематическое изображение. Настолько легче произвести схему базы данных, если существуют отношения внешнего ключа, правильно используемые.
-
поддержка Инструмента. Намного легче создать модели данных с помощью Visual Studio 2008 , который может использоваться для LINQ to SQL, если существуют надлежащие отношения внешнего ключа.
, Таким образом, я предполагаю, что моя точка - то, что мы нашли, что, если мы делаем большую ручную работу SQL (создают запрос, выполнение запросов, и тому подобное) внешние ключи не обязательно важны. Как только Вы начинаете входить в использование инструментов, тем не менее, они становятся намного более полезными.
Можно просмотреть внешние ключи как ограничение, что,
- Справка поддерживает целостность данных
- Шоу, как данные связаны друг с другом (который может помочь в осуществлении бизнес-логики и правил)
- , Если используется правильно, может помочь увеличить эффективность, с которой данные выбираются от таблиц.
Я думаю об этом с точки зрения стоимости/преимущества... В MySQL , добавляя ограничение является единственной дополнительной строкой DDL. Это - просто горстка ключевых слов и несколько секунд мысли. Это - единственная "стоимость", по-моему...
Инструменты любят внешние ключи. Внешние ключи предотвращают неправильные данные (то есть, осиротевшие строки), который не может влиять на бизнес-логику или функциональность и для этого остаться незамеченным и расти. Это также предотвращает разработчиков, которые незнакомы со схемой от реализации всех блоков работы, не понимая, что они пропускают отношения. Возможно, все является большим в рамках Вашего текущего приложения, но если бы Вы пропустили что-то, и когда-нибудь что-то неожиданное добавляется (думайте создание отчетов воображения), то Вы могли бы быть в месте, где необходимо вручную очистить неправильные данные, это накапливалось начиная с начала схемы без базы данных осуществленная проверка.
мало времени это берет для шифровки то, что уже находится в голове, когда Вы соединяете вещи, мог сохранить Вас или кого-то еще набор месяцев горя или лет в будущем.
вопрос:
там какое-либо другое использование для внешних ключей? Я пропускаю что-то здесь?
Это немного загружается. Вставьте комментарии, добавление отступа или переменное именование вместо "внешних ключей"... Если Вы уже понимаете рассматриваемую вещь отлично, она бесполезна" Вам.
Они важны, потому что Ваше приложение не является единственным способом, которым данными можно управлять в базе данных. Ваше приложение может обработать ссылочную целостность так честно, как это хочет, но все это, взятия являются одним типом с правильными полномочиями прийти и выпустить вставку, удалить или обновить команду на уровне базы данных и все Ваше осуществление ссылочной целостности приложения, обойдено. Вставление ограничений FK на уровне базы данных означает, что, запрещая этого типа, принимающего решение отключить ограничение FK прежде, чем дать их команду, ограничение FK вызовет плохое, вставлять/обновлять/оператор удаления для сбоя с нарушением ссылочной целостности.
Они не строго необходимы в способе, которым ремни безопасности не строго необходимы. Но они могут действительно сохранить Вас от выполнения чего-то глупого, которое портит Вашу базу данных.
настолько более хорошо отладить ограничительную ошибку FK, чем должны восстановить удаление, которое повредило Ваше приложение.
, Насколько я знаю, внешние ключи используются, чтобы помочь программисту управлять данными корректным способом.
FKs позволяют DBA защищать целостность данных от нащупывания пользователей когда программист сбои , чтобы сделать так, и иногда защищать от нащупывания программистов.
предположим программист уже на самом деле делает это правильным способом, затем нам действительно нужно понятие внешних ключей?
Программисты смертны и ненадежны. FKs описание , который делает их тяжелее для завинчивания.
там какое-либо другое использование для внешних ключей? Я пропускаю что-то здесь?
, Хотя это не то, почему они были созданы, FKs обеспечивают сильный надежный вывод подсказок схематическому изображению инструментов и конструкторам запросов. Это передается конечным пользователям, кому отчаянно нужны сильные надежные подсказки.
Внешние ключи позволяют кому-то, кто не видел Вашу базу данных прежде для определения отношений между таблицами.
Все может быть прекрасным теперь, но думать, что произойдет, когда Ваш программист уедет, и кто-то еще должен вступить во владение.
Внешние ключи позволят им понимать структуру базы данных, не траля через тысячу строк кода.
Я предполагаю, что Вы говорите [приблизительно 113] ограничения внешнего ключа, осуществленные базой данных . Вы, вероятно, уже используете внешние ключи, Вы просто не сказали базу данных об этом.
предположим программист уже на самом деле делает это правильным способом, затем нам действительно нужно понятие внешних ключей?
Теоретически, нет. Однако никогда не было части программного обеспечения без ошибок.
Ошибки в коде приложения обычно не настолько опасны - Вы определяете ошибку и фиксируете ее, и после этого выполнение приложения гладко снова. Но если ошибка позволяет currupt данным вводить базу данных, то Вы застреваете с ним! Очень трудно восстановиться с поврежденных данных в базе данных.
Рассматривают, позволила ли тонкая ошибка в FogBugz поврежденному внешнему ключу быть записанным в базе данных. Могло бы быть легко исправить ошибку и быстро продвинуть фиксацию клиентам в выпуске bugfix. Однако, как должен поврежденные данные в десятках баз данных быть зафиксированным? Корректный код мог бы теперь внезапно повредиться, потому что предположения о целостности внешних ключей больше не содержат.
В веб-приложениях у Вас обычно только есть одна программа, говорящая с базой данных, таким образом, существует только одно место, где ошибки могут повредить данные. В корпоративном приложении могло бы быть несколько независимых приложений, говорящих с той же базой данных (не говоря уже о людях, работающих непосредственно с оболочкой базы данных). Нет никакого способа быть уверенным, что все приложения следуют за теми же предположениями без ошибок, всегда и навсегда.
, Если ограничения кодируются в базе данных, то худшее, которое может произойти с ошибками, - то, что пользователю показывают ужасное сообщение об ошибке о [приблизительно 111] ограничение SQL , не удовлетворенное. Это очень prefereable к разрешению currupt данные в Вашу базу данных предприятия, где это в свою очередь повредит все Ваши приложения или просто приведет ко всем видам неправильного или вводящего в заблуждение вывода.
, О, и ограничения внешнего ключа также улучшает производительность, потому что они индексируются по умолчанию. Я не могу думать ни о какой причине не для использования ограничений внешнего ключа.
Существует ли преимущество для не наличия внешних ключей? Если Вы не используете дрянную базу данных, FKs не это трудно для установки. Итак, почему у Вас была бы политика предотвращения их? Это - одна вещь иметь соглашение о присвоении имен, в котором говорится столбец ссылки другой, это - другой, чтобы знать, что база данных на самом деле проверяет что отношения для Вас.
Без внешнего ключа, как Вы говорите, что две записи в различных таблицах связаны?
я думаю, к чему Вы обращаетесь, ссылочная целостность, где дочерней записи не позволяют быть созданной без существующей родительской записи и т.д. Они часто известны как ограничения внешнего ключа - но не должны быть перепутаны с существованием внешних ключей во-первых.
предположим программист уже на самом деле делает это правильным способом
, Создание такой гипотезы, кажется, мне чрезвычайно плохая идея; в общем программном обеспечении феноменально ошибочно.
И в этом суть, действительно. Разработчики не могут разобраться в вещах, так обеспечение базы данных не может быть заполнено неправильными данными, Хорошая Вещь.
, Хотя в идеальном мире, естественные соединения использовали бы отношения (т.е. ограничения FK) вместо того, чтобы соответствовать именам столбцов. Это сделало бы FKs еще более полезный.
Лично, я выступаю за внешние ключи, потому что это формализует отношения между таблицами. Я понимаю, что Ваш вопрос предполагает, что программист не представляет данные, которые нарушили бы ссылочную целостность, но я видел слишком много экземпляров, где ссылочная целостность данных нарушена, несмотря на лучшие намерения!
ограничения Перед внешним ключом (иначе декларативная ссылочная целостность или DRI) много времени было проведено, реализовав эти отношения с помощью триггеров. То, что мы можем формализовать отношения декларативным ограничением, очень мощно.
@John - Другие базы данных могут автоматически создать индексы для внешних ключей, но SQL Server не делает. В SQL Server отношения внешнего ключа являются только ограничениями. Вы должны, определил Ваш индекс на внешних ключах отдельно (который может иметь выгоду.)
Редактирование: я хотел бы добавить, что, IMO, использование внешних ключей в поддержку НА УДАЛЯЕТ, или КАСКАД ON UPDATE является не обязательно хорошей вещью. На практике я нашел, что каскад на удаляет, должен быть тщательно рассмотрен на основе отношений данных - например, сделать у Вас есть естественный родительский ребенок, где это может быть в порядке или является связанной таблицей ряд справочных значений. Используя каскадные обновления подразумевает, что Вы позволяете первичному ключу одной таблицы быть измененным. В этом случае у меня есть общее философское разногласие в этом, первичный ключ таблицы не должен изменяться. Ключи должны быть по сути постоянными.
Да.
- Они сохраняют Вас честными
- , Они сохраняют новых разработчиков честными
- , можно сделать
ON DELETE CASCADE - , Они помогают Вам генерировать хорошие схемы, которые сам объясняют ссылки между таблицами
Схема базы данных без ограничений FK похожа на управление без ремня безопасности.
Однажды, Вы будете сожалеть о нем. Не проводя, что мало дополнительного времени на основных принципах дизайна и целостности данных является верным способом гарантировать головные боли позже.
Вы приняли бы код в своем приложении, которое это было неаккуратно? Это непосредственно получило доступ к членским объектам и изменило структуры данных непосредственно.
, Почему Вы думаете, что это было сделано твердым и даже недопустимый в современных языках?
Я не могу предположить разрабатывать базу данных без внешних ключей. Без них в конечном счете Вы обязаны сделать ошибку и повредить целостность Ваших данных.
Они не , потребовал , строго говоря, но преимущества огромны.
я вполне уверен, что FogBugz не имеет ограничений внешнего ключа в базе данных. Мне было бы интересно слышать, как Fog Creek Software команда структурирует их код, чтобы гарантировать, что они никогда не будут представлять несоответствие.
Внешние ключи могут также помочь программисту записать меньше кода с помощью вещей как ON DELETE CASCADE. Это означает, что, если у Вас есть одна таблица, содержащая пользователей и другого содержащего заказы или что-то, затем удаляя пользователя могло автоматически удалить все заказы, которые указывают тому пользователю.
Я думаю , некоторая единственная вещь в какой-то момент должна быть ответственна за обеспечение допустимых отношений.
, Например, Ruby on Rails не использует внешние ключи, но он проверяет все отношения сам. Если Вы только когда-либо получаете доступ к своей базе данных из того приложения Ruby on Rails, это прекрасно.
Однако, если у Вас есть другие клиенты, которые пишут в базу данных, затем без внешних ключей, они должны реализовать свою собственную проверку. У Вас тогда есть две копии кода доступа, которые, скорее всего, отличаются, который любой программист должен быть в состоянии сказать, кардинальный грех.
В той точке, внешние ключи действительно необходимы, поскольку они позволяют Вам перемещать ответственность перед единственной точкой снова.
FK очень важны и должны всегда существовать в вашей схеме, , если вы не eBay .
Уменьшение энтропии. Уменьшите вероятность возникновения хаотических сценариев в базе данных. У нас тяжелые времена, поскольку мы рассматриваем все возможности, поэтому, на мой взгляд, снижение энтропии является ключом к поддержанию любой системы.
Когда мы делаем предположение, например: у каждого заказа есть покупатель, это предположение должно выполняться автор что-то . В базах данных этим «чем-то» являются внешние ключи.
Я думаю, что это стоит компромисса в скорости разработки. Конечно, вы можете быстрее писать код без них, и, вероятно, поэтому некоторые люди их не используют. Лично я убил несколько часов с NHibernate и некоторым ограничением внешнего ключа, которое раздражает, когда я выполняю какую-то операцию. ОДНАКО, я знаю, в чем проблема, поэтому это не проблема. Я использую обычные инструменты, и есть ресурсы, которые помогут мне обойти эту проблему, возможно, даже люди, которые могут помочь!
Альтернативный вариант - позволить ошибке закрасться в систему (и при наличии достаточного количества времени это произойдет), когда внешний ключ не установлен, и ваши данные становятся несовместимыми. Затем вы получите необычный отчет об ошибке, исследуйте и «ОН». База данных прикручена. Теперь, сколько времени потребуется, чтобы это исправить?