Внешний ключ MySQL разрешает NULL?
Я собираю по кусочкам веб-сайт изображений. Базовая схема довольно проста в MySQL, но у меня возникли проблемы с попыткой представить возможные флаги администратора, связанные с изображением («несоответствующий», «защищенный авторским правом» и т. д.). Мое текущее представление таково:
tblImages (
imageID INT UNSIGNED NOT NULL AUTO_INCREMENT,
...
);
tblImageFlags (
imageFlagID INT UNSIGNED NOT NULL AUTO_INCREMENT,
imageID INT UNSIGNED NOT NULL,
flagTypeID INT UNSIGNED NOT NULL,
resolutionTypeID INT UNSIGNED NOT NULL,
...
);
luResolutionTypes (
resolutionTypeID INT UNSIGNED NOT NULL AUTO_INCREMENT,
resolutionType VARCHAR(63) NOT NULL,
...
);
(усечено для удобства чтения; клянусь, разные внешние ключи и индексы в порядке)
tblImageFlags.flagTypeID имеет внешний ключ в поисковой таблице типов флагов, и, как вы можете представить, tblImageFlags.resolutionTypeIDдолжен имеет внешний ключ на luResolutionTypes.resolutionTypeID. Проблема в том, что при первой выдаче флага нет логического типа разрешения (я бы назвал это хорошим использованием NULL); однако, если значение установлено, оно должно иметь внешний ключ для таблицы поиска.
Я не могу найти обходной путь синтаксиса MySQL для этой ситуации. Он существует? Лучшими участниками, занявшими второе место, стали:
- Добавить "немодерируемый" тип разрешения
- Добавьте запись
NULLвluResolutionTypes.resolutionTypeID(будет ли это работать в столбцеAUTO_INCREMENT?)
Спасибо за понимание!
PS Бонус указывает на то, кто говорит мне, что это в случае с базами данных «индексы» или «индексы».
Следовать за: спасибо Биллу Карвину за указание на то, что оказалось синтаксической ошибкой в структуре таблицы (не устанавливайте столбец на NOT NULL, если вы хотите, чтобы он разрешал NULL!). И как только у меня будет достаточно кармы, чтобы дать вам эти бонусные баллы, я буду :)
Ответы 1
Вы можете решить эту проблему, разрешив NULL в столбце внешнего ключа tblImageFlags.resolutionTypeID.
PS Бонус указывает на то, кто говорит мне, что это в случае с базами данных «индексы» или «индексы».
Множественное число индекс должно быть индексы.
Согласно "Современное американское использование" Брайана А. Гарнера:
For ordinary purposes, indexes is the preferable plural, not indices. ... Indices, though less pretentious than fora or dogmata, is pretentious nevertheless. Some writers prefer indices in technical contexts, as in mathematics and the sciences. Though not the best plural for index, indices is permissible in the sense "indicators." ... Avoid the singular indice, a back-formation from the plural indices.
@glyph: В этом нет смысла. Если столбец FK не может ссылаться на конкретную запись PK, сделайте FK допускающим значение NULL. Если столбец FK не может быть пустым, то он должен ссылается на существующую запись в столбце PK. Использование 0 или другого фальшивого значения для обозначения того, что "запись не указана", недействительна.
В этом случае (по крайней мере, в MySQL) внешний ключ не будет разрешен, потому что fk не может быть нулевым, если pk не равен нулю, а pks в mysql всегда не равны нулю. Я понимаю, как обеспечить ссылочную целостность между полем fk и столбцом pk, если значение присутствует, но также разрешить нулевые значения. Использование 0 в качестве фиктивной записи, безусловно, требует обходных решений в другом месте вашего приложения, но это действительно так.
@glyph: Нет, вы можете разрешить null в FK, по крайней мере, если вы не объявляете столбец FK как NOT NULL.
Ну, я только что провел эксперимент, и моя проблема заключалась в том, что у моих полей pk было значение по умолчанию. Поле PK имеет значение NULL, но по умолчанию отсутствует, тогда поле FK может быть NULL, и все в порядке.
Индексы действительно более распространены в американском английском, но в меньшей степени в британском английском, где индексы используются чаще, особенно в техническом контексте ... grammarist.com/usage/indexes-indices
@Basic, спасибо за понимание! Я понял разницу, поскольку индексы используется в контексте мер или индикаторов, тогда как индексы более уместен, когда речь идет о сборе организованных данных.
Отлично ... теперь мне нужно проанализировать, звучат ли мои архитектуры БД претенциозно или нет.
@CamiloMartin Это не урок английского, это урок Америки. Для американца было бы претенциозно объяснять англоговорящим, как говорить на их родном языке!
@ user3791372 * Американский английский. Но как не носитель языка: используют ли британцы «индексы»?
@ShaheenGhiassy, разве вы не читали ту часть, где в OP говорится: «PS Bonus указывает на то, кто мне говорит, что это в случае с базами данных -« индексы »или« индексы »? Вы слишком усердны.
@BillKarwin - Я скучал по этому поводу. Спасибо за то, что показал мне то, что я пропустил
Обычно я очень придирчив к правильной грамматике, но ссылки на индексы меня совсем не беспокоят.
@Prusprus фактически пишется претенциозный.
Как вопрос о переполнении стека превратился в языковой курс?
@ADTC, ОП попросил помощи по использованию термина программирования. Я считаю, что это вопрос, связанный с программированием. :-)
Что вы делаете с внешними ключами для столбцов первичного ключа, которым не разрешено быть NULL? Это проблема, которая преследует мои приложения на протяжении многих лет, и иногда я использую 0 или отказываюсь от отношения внешнего ключа, но это не оптимально.