MySQL - Должен ли я использовать многоколоночные первичные ключи в каждой дочерней таблице?
Setup:
Я пытался понять разницу между идентифицирующими и неидентифицирующими отношениями, когда нашел эту замечательную статью на stackexchange. В чем разница между идентифицирующими и неидентифицирующими отношениями?
Прочитав несколько комментариев, я задал еще один вопрос о проблеме, с которой я столкнулся.
Вопрос:
Должен ли я использовать многостолбцовые первичные ключи в каждой дочерней таблице и каковы преимущества/недостатки этого?
Чтобы лучше проиллюстрировать свой вопрос, я создал пример ниже. Я также включил комментарии, которые заставили меня задать этот вопрос.
Пример:
В моей ситуации я знаю building_id и мне нужно получить bed.data.
#1 - Моя текущая структура БД:
TABLE { FIELDS }
-----------------------------------------------------------------------
building { id, data }
floor { id, building_id, data }
room {id, floor_id, data }
bed {id, room_id, data }
Этот тип структуры таблицы потребует от меня использования нескольких объединений для получения нужных мне данных. Это не очень важно, но довольно неприятно, поскольку я часто сталкиваюсь с такой ситуацией.
#2 - Моя интерпретация предложенной Биллом Карвином структуры БД (см. комментарии к статье ниже):
TABLE { FIELDS }
-----------------------------------------------------------------------
building { id, data }
floor { id, building_id, data }
room {id, building_id, floor_id, data }
bed {id, building_id, floor_id, room_id, data }
Эта структура таблицы, похоже, устраняет необходимость в джойнах в моей ситуации. Так каковы же недостатки этой структуры таблиц? Мне очень нравится идея не делать так много операторов объединения.
Комментарии к статье:
В чем разница между идентифицирующими и неидентифицирующими отношениями?
@hobodave: Это аргумент "конвенция важнее конфигурации". Некоторые школы считают, что каждая таблица должна определять свой первичный ключ для одностолбцового псевдоключа с именем id, который автоматически генерирует свои значения. Такие платформы приложений, как Rails, популяризировали этот принцип по умолчанию. Они рассматривают естественные ключи и многоколоночные ключи как отклонение от своих конвенций, необходимое при использовании "старых" баз данных. Многие другие фреймворки последовали этому примеру. - Bill Karwin Mar 10 '10 at 23:06
Кажется, что "правильное" построение идентифицирующих отношений приведет к несносно огромным первичным ключам. Например, здание имеет этаж, комната имеет кровать. PK для Bed будет (bed_id, floor_id, room_id, building_id). Странно, что я никогда не видел этого на практике и не слышал, чтобы это предлагалось как способ сделать что-либо. Это очень много избыточных данных в PK. - hobodave Mar 10 '10 at 23:34
@hobodave: Я видел многоколоночные первичные ключи, которые еще больше. Но я принимаю вашу точку зрения. Считайте, что первичные ключи с несколькими столбцами передают больше информации; вы можете запросить в таблице Beds все кровати в определенном здании, не делая никаких объединений. - Bill Karwin Mar 11 '10 at 1:00