Я должен использовать составные первичные ключи или нет?

Аналогичные вопросы задавались по SO, и нет единого мнения;)

Если вы разрабатываете веб-приложение, вам понравятся pk в один столбец, поскольку они делают ваши URL проще.

Для обертывания последовательности вам понадобится 2 миллиарда записей в одной таблице (32-битная) или 10 ^ 18 с 64-битными pk.

Кстати, ваша модель данных не позволяет использовать персонажей фильма с неизвестным актеры.

По моему личному мнению, вам следует избегать составных первичных ключей из-за нескольких причины:

1. Будущие изменения: когда вы проектируете базу данных, вы иногда упускаете из виду то, что в будущем станет важным. Важным примером этого является мысль, что комбинация двух или более полей является уникальной (и, таким образом, может стать первичным ключом), тогда как в будущем вы захотите разрешить в них NULL или другие неуникальные значения. Наличие одного первичного ключа - хорошее решение против таких изменений.

2. Единообразие: если каждая таблица имеет уникальный числовой идентификатор, и вы также поддерживаете некоторый стандарт относительно ее имени (например, «ID» или «tablename_id»), код и SQL, относящиеся к ней, будут более ясными (на мой взгляд).

Есть и другие причины, но это лишь некоторые.

Главный вопрос, который я задам, - почему бы не использовать отдельный первичный ключ, если у вас есть уникальный набор полей? Какая стоимость? Дополнительный целочисленный индекс? Это не так уж и плохо.

Надеюсь, что это поможет.

В Ruby for Rails, если явно не указано иное, ваша таблица Role будет похожа на описанную вами (если столбцы на самом деле являются идентификаторами из других таблиц) . Тем не менее, в базе данных вы можете обеспечить уникальные комбинации, определив уникальный индекс для этих трех столбцов, хотя бы для того, чтобы помочь базе данных оптимизировать ваши запросы. Имея этот уникальный индекс и структуру, в любом случае не использующую какой-либо другой первичный ключ, нет необходимости в дополнительном числовом первичном ключе в вашей таблице Роль . При этом уникальный индекс можно было бы вместо этого определить как составной первичный ключ.

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

Итак:

Я бы использовал их только в таблицах соединений. Единственный способ полностью гарантировать уникальность и непротиворечивость каждого идентификатора записи - использовать синтетический ключ.

Составные ключи кажутся нормальными в теории, поэтому их так и хочется использовать, но практика показала, что они обычно указывают на наличие изъяна в вашей модели данных. Что еще хуже, во многих случаях они не могут гарантировать уникальность при достаточно большом наборе данных. Наборы данных всегда растут со временем, поэтому их использование может означать, что вы заложили бомбу в свое приложение, которая взорвется только тогда, когда приложение какое-то время используется в производственной среде.

Я думаю, что люди недооценивают ORM. У каждого основного языка программирования есть де-факто ORM, и в течение многих лет потому что они решают фундаментальную несовместимость между объектно-ориентированными и реляционными структурами. Пытаться написать любое сложное, тестируемое объектно-ориентированное программное обеспечение для баз данных SQL без ORM в лучшем случае очень неэффективно.

Хорошие ORM также предоставляют методы и инструменты, которые значительно упрощают создание и поддержание согласованной высококачественной схемы базы данных, поэтому в среднем команда выйдет далеко вперед, работая с ORM. Схема ручной работы больше похожа на написание C ++ ... люди могут это делать, но в реальном мире так сложно поддерживать качество в течение долгого времени, что средний продукт не является хорошим.

Хорошие ORM также предоставляют методы и инструменты, которые значительно упрощают создание и поддержание согласованной высококачественной схемы базы данных, поэтому в среднем команда выйдет далеко вперед, работая с ORM. Схема ручной работы больше похожа на написание C ++ ... люди могут это делать, но в реальном мире так сложно поддерживать качество в течение долгого времени, что средний продукт не является хорошим.

Хорошие ORM также предоставляют методы и инструменты, которые значительно упрощают создание и поддержание согласованной высококачественной схемы базы данных, поэтому в среднем команда выйдет далеко вперед, работая с ORM. Схема ручной работы больше похожа на написание C ++ ... люди могут это делать, но в реальном мире так сложно поддерживать качество в течение долгого времени, что средний продукт не является хорошим.

Это религиозная вещь. Я использую естественные ключи и избегаю суррогатов. У меня нет проблем с составными ключами ни в теории, ни на практике.

Только самая тривиальная логическая модель не будет включать составных ключей. Назовите меня ленивым, но я не вижу необходимости усложнять модель данных, вводя суррогаты в физическую модель при реализации. Конечно, я бы рассмотрел один на столе, если были обнаружены проблемы с производительностью, но я использую тот же подход, что и для денормализации, то есть в крайнем случае. Привычное использование суррогатов означает преждевременную оптимизацию, IMO.

Мое общее мнение ... нет. не используйте составные первичные ключи.

Они обычно усложняют ORM, если вы их используете (ORM иногда заходят так далеко, что называют составные первичные ключи «устаревшим поведением») и, как правило, если вы используете несколько ключей, один или несколько из них будут иметь тенденцию быть естественными, а не техническими ключами, что для меня является более серьезной проблемой: IMHO, вам определенно следует отдавать предпочтение техническим первичным ключам.

Подробнее об этом в Ошибки разработки баз данных, сделанные AppDevelopers . . 1122778]

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

Некоторые ORM плохо справляются с составными первичными ключами, поэтому, возможно, безопаснее создать суррогатный автоматический -целое число для первичного ключа и покрыть столбцы некластеризованным индексом.

Религиозные войны были и продолжаются по этому поводу.

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

Специалисты по работе с данными говорят об «уникальности», которая воспринимается ОО как «ревностная», и скажут вам, что единственное, что имеет значение, - это то, что если бизнес сообщает вам, что комбинация (значений) атрибута X и атрибут Y должны быть уникальными, тогда ваша задача - следить за тем, чтобы база данных применяла это бизнес-правило уникальности объединенного X + Y.

Как вы хотите получить ответ на свой вопрос, зависит только от того, какую религию вы предпочитаю. Моя личная религия - религия данных. Эта религия доказала свою способность выдерживать любую шумиху и любую тенденцию с 1969 года.

и сообщит вам, что единственное, что имеет значение, это то, что если бизнес сообщает вам, что комбинация (значений для) атрибута X и атрибута Y должна быть уникальной, тогда ваша задача - следить за тем, чтобы база данных обеспечивала выполнение этого бизнес-правила. уникальности сочетания X + Y.

Как вы хотите получить ответ на свой вопрос, зависит только от того, какую религию вы предпочитаете. Моя личная религия - религия данных. Эта религия доказала свою способность выдерживать любую шумиху и любую тенденцию с 1969 года.

и сообщит вам, что единственное, что имеет значение, это то, что если бизнес сообщает вам, что комбинация (значений для) атрибута X и атрибута Y должна быть уникальной, тогда ваша задача - следить за тем, чтобы база данных обеспечивала выполнение этого бизнес-правила. уникальности сочетания X + Y.

Как вы хотите получить ответ на свой вопрос, зависит только от того, какую религию вы предпочитаете. Моя личная религия - религия данных. Эта религия доказала свою способность выдерживать любую шумиху и любую тенденцию с 1969 года.

Я почти никогда не встречал случая, когда составной ключ был бы хорошей идеей (исключение, объединяющая таблица, состоящая только из двух суррогатных ключей). В первую очередь вы тратите место в дочерних таблицах. Вы снижаете производительность в объединениях, поскольку целочисленные объединения обычно выполняются намного быстрее. Если у вас есть составной ключ в качестве кластеризованного индекса (здесь речь идет о SQL Server), вы делаете базу данных менее эффективной при хранении записей и менее эффективной при построении других индексов - все из которых используют индекс clusterd.

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

Итак, вы думаете об использовании метода, который снижает производительность, приводит к некачественному использованию памяти и хранилища базы данных, использует намного больше места в дочерних записях (еще одна трата ресурсов) и требует болезненного обновления того, что может быть миллионами дочерних записей, когда вещи меняются. И что может затруднить использование ORM? Почему ты бы так поступил? Потому что вам лень поставить суррогатный ключ, а затем определить уникальный индекс для потенциального составного ключа? Есть ли вообще какой-то выигрыш от использования составного индекса? Из-за отсутствия 5 минут работы вы постоянно портите свою базу данных?