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

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

Две таблицы, которые я разрабатываю, я настраиваю с помощью поиска «типа идентификатора» (внешний ключ для перечисления типов/таблиц, которым принадлежит идентификатор), а затем значение идентификатора FK. Мне интересно, должен ли я сделать это для всех внешних ключей таблицы, чтобы быть последовательным. Для этих двух таблиц их, возможно, потребуется объединить с другой таблицей, в зависимости от того, о чем будет запись. Подумайте, что люди привязаны к разным аспектам процесса, поэтому запись о человеке будет связана с одной таблицей или с другой, в зависимости от того, где они участвуют в процессе.

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

Если это не имеет смысла, дайте мне знать, и я постараюсь объяснить лучше.

Спасибо!


person missscripty    schedule 16.06.2017    source источник
comment
Тебя плохо видно. Например, я настроил поиск типа идентификатора ([...]), а затем значение идентификатора FK - мы не знаем, что вы подразумеваете под настройкой, и мы не знаем, какие FK куда. Сделайте референсы понятными. Пожалуйста, дайте DDL, примеры данных и значения таблиц. PS FK являются ограничениями. Говорят, что подстроки появляются и в других местах. Они сообщают СУБД, какие состояния базы данных могут возникать, данные, что означают таблицы и какие бизнес-ситуации могут возникнуть. Создайте значения таблицы. Используйте идентификаторы для идентификации/именования бизнес-объектов/вещей. Обычно нет необходимости в идентификаторе таблицы ассоциаций, ее сущности образуют ПК. ФК в последнюю очередь.   -  person philipxy    schedule 17.06.2017
comment
Согласно первому предложению самостоятельного ответа, речь идет о (?!) столбце внешнего ключа, который ссылается на разные таблицы на основе другого столбца идентификатора таблицы (см. мой комментарий там). Так что это дубликат Внешний ключ MySQL использование более одного поля для ссылки на первичный ключ из другой таблицы и/или Дизайн базы данных - статьи, посты в блогах, фото, истории.   -  person philipxy    schedule 17.06.2017


Ответы (1)


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

Совет состоит в том, чтобы иметь таблицу людей, а затем несколько таблиц перекрестных ссылок на людей, по одной для каждой области данных, с которой нужно связать человека. Каждая таблица CR будет иметь ненулевой внешний ключ и записи только в 1 таблицу, на которую ссылается FK. Также будет идентификатор типа человека, так что человек может иметь более одного типа/списка в пределах такого количества CR, где они должны существовать.

Если кто-то не согласен, я буду более чем счастлив получить столько дублей, сколько смогу.

person missscripty    schedule 16.06.2017
comment
В вашем вопросе нет намека на то, о чем идет речь в первом предложении этого ответа. Этот анти-шаблон FK обычно является неправильным способом моделирования подтипов SQL/базы данных. (Погуглите мои комментарии по этому поводу в stackoverflow. Остальная часть этого ответа так же неясна, как и ваш вопрос. Вам нужно перестать обозначать вещи, которые вы не сказали, словами, которые приходят на ум (например, область данные) и скажите, что вы имеете в виду. Примеры помогут, но вам все равно нужно сказать, что они являются примерами из. - person philipxy; 17.06.2017
comment
Ограничение FK сохраняется в проекте, когда значения подстроки для списка столбцов должны появляться для другого списка столбцов. Мы объявляем FK, чтобы СУБД отклоняла недопустимые обновления. Если значения столбца ограничены только одним из нескольких других мест (для столбца типа), то это не пример владения FK; это другое ограничение. Отдельные наборы столбцов, допускающих значение NULL, для каждой целевой таблицы будут FK. Столбец типа может указывать, какие FK (или таблицы, если они есть на каждую таблицу) хранятся. Таким образом, может ли каждый FK быть нулевым. Но все это антишаблоны для подтипов. Таким образом, этот ответ. - person philipxy; 20.06.2017