Должен ли я использовать суррогатный ключ (id = 1) или естественный первичный ключ (tag = 'sqlalchemy') для моей модели sqlalchemy? - PullRequest
1 голос
/ 21 июня 2011

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

class MyClass(Base):
    __tablename__ = 'myclass'
    id = Column(Integer, primary_key=True)

Если у меня есть простой класс, такой как тег, где я планирую хранить только одинв любом случае, если я использую sqlalchemy, что я получу благодаря суррогатному первичному ключу?Одна из книг по SQL, которую я читаю, предполагает, что ORM являются законным использованием «антипаттерна», но предполагаемые им ORM звучат больше как ActiveRecord или Django.В моей модели это встречается в нескольких местах, но вот одно из них:

class Tag(Base):
    __tablename__ = 'tag'
    id = Column(Integer, primary_key=True) #should I drop this and add primary_key to Tag.tag?
    tag = Column(Unicode(25), unique=True) 
    ....

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

Ответы [ 3 ]

3 голосов
/ 21 июня 2011

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

Поищите в SO (и в Google) более общие вопросы о том, как выбрать первичный ключ, например: https://stackoverflow.com/search?q=primary+key+natural+surrogate+database-design ( Суррогат противнатуральные / бизнес-ключи , Вопрос проектирования реляционной базы данных - суррогатный ключ или натуральный ключ? , Когда не следует использовать суррогатные первичные ключи? , ...)


Я предполагаю, что таблица Tag не будет очень большой или очень динамичной.В этом случае I попытается использовать tag в качестве первичного ключа, если только нет важных причин для добавления некоторого невидимого для конечного пользователя первичного ключа, например:

  • низкая производительность при реальных данных (измеренная, а не воображаемая),

  • частые изменения имен тегов (но тогда я все равно буду использовать некоторые уникальные строки на основедля первого использованного имени тега в качестве ключа),

  • невидимое закулисное объединение тегов (но, см. предыдущий пункт),

  • проблемы с различными сопоставлениями - сравнение международных данных - в вашей РСУБД (но, ...)

  • ...


В целом я заметил, что люди склонны ошибаться в обоих направлениях:

  • , используя сложные многопольные «естественные» ключи (где отдельные поля сами являются непрозрачными числами), когда строки таблицы имеютих личность и было бы полезно иметь свои собственные суррогатные идентификаторы,

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

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

1 голос
/ 21 июня 2011

Лично я предпочитаю суррогатные ключи в большинстве мест; Две основные причины этого: 1) целочисленные ключи обычно меньше / быстрее и 2) обновление данных не требует каскадов. Этот второй момент довольно важен для того, что вы делаете; Если существует множество таблиц, ссылающихся на таблицу тегов, помните, что если кто-то хочет обновить тег (например, исправить орфографическую ошибку / ошибку в регистре или использовать более / менее конкретное слово и т. Д.), Обновление необходимо выполнить одновременно по всем таблицам.

Я не говорю, что вы никогда не должны использовать естественный ключ. Если я уверен, что естественный ключ никогда не изменится, я рассмотрю естественный ключ. Просто будьте уверены, в противном случае это становится болью для поддержания.

0 голосов
/ 02 марта 2016

Всякий раз, когда я вижу, что люди (сверх) используют суррогатные ключи, я вспоминаю статьи Роя Ханна в блоге на эту тему, особенно вторую и третью статьи:

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

В настоящее время использование суррогатного ключа напоминает мне о ранних годах 21-го века, когда люди использовали XML буквально для всего, как того, где он был, так и того, где он не принадлежал.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...