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

1

На стороне базы данных я понимаю, что естественный первичный ключ является предпочтительным, если он не является чрезмерно длинным, что может вызвать проблемы с индексированием. Но когда я читаю проекты, которые используют 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) 
    ....

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

  • 1
    Я бы лично использовал естественный первичный ключ. ОТО, я не эксперт по SQL и не могу должным образом рассмотреть все плюсы и минусы.
  • 0
    Это тоже мое предубеждение, но использование естественных ключей кажется таким редким выбором в этой среде, поэтому я хотел бы иметь некоторый контекст относительно того, почему это может быть, особенно, поскольку среда, как представляется, сохраняет большинство естественных взаимодействий с базой данных. ,
Теги:
orm
sqlalchemy
primary-key

3 ответа

3
Лучший ответ

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

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

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

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

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

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

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

  • ...

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

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

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

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

Поделиться
  • 0
    Я ценю ваши комментарии и, конечно же, признаю отличный совет. Ваша идея «ошибиться, избегая суррогатного ключа», как даже возможность в мире, отличном от ORM, является новой для меня и полезной. И я понимаю, что вы хотите сказать, что мой ORM не имеет значения. Но я надеюсь на специфическое для sqlalchemy подтверждение этой точки, и, в частности, на лучшее представление о том, что получено или потеряно в этой структуре (если что-нибудь). Тем не менее, большое спасибо за предоставление такого элегантного общего руководства.
  • 0
    @Profane: я не советую избегать суррогатных ключей. Есть много случаев, когда это правильный выбор. Я имел в виду следующее: не искать то, что авторы ORM находят более легким для реализации (последовательные числа или GUID), но что такое хороший дизайн базы данных. Тогда вы сможете взвешивать аргументы, которые действительно имеют значение в долгосрочной перспективе.
Показать ещё 1 комментарий
1

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

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

Поделиться
  • 0
    Спасибо за полезную контрперспективу (в отличие от приведенного выше естественного ключа). Возможно, это главная причина, почему я вижу так много таких моделей с «id» для первичного ключа. Все еще надеясь, что кто-то, кто понимает внутреннюю механику sqlalchemy, может дать некоторое представление о том, имеет ли это значение в контексте конкретной структуры. Еще раз спасибо за вклад.
0

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

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

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

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню