Есть ли причина иметь отдельный первичный ключ id, если у меня уже есть уникальный ключ?

Question

Скажем, я работаю с пользователями Steam, у каждого есть уникальный SteamID. Мне все еще нужен отдельный столбец id, чтобы действовать как первичный ключ, или я могу просто использовать SteamID? То есть это достаточно (с помощью Flask-SQLAlchemy):

class User(db.Model): 
    steamid = db.Column(db.String(20), primary_key=True, unique=True) 
    name = db.Column(db.String(120)) 
    # more stuff 

Или я все еще включать в себя уникальный id, как показано в Flask-SQLAlchemy's examples:

class User(db.Model): 
    id = db.Column(db.Integer, primary_key=True) 
    steamid = db.Column(db.String(20), unique=True) 
    name = db.Column(db.String(120)) 
    # more stuff 

И если да, то почему ?

Answer 1

Главный аргумент против него - производительность, целые первичные ключи обычно быстрее запрашивают и работают.

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

Answer 2

Для большинства случаев SteamID должен быть достаточным. Это может быть проблематично, если идентификаторы близки, а разница - это пробел в ID или что-то в этом роде. Использование uniqueId's - действительно лучший способ.

Answer 3

Хотя верно, что числовое значение для значения идентификатора немного быстрее для сортировки и определения местоположения системой, разница вряд ли будет заметной или даже измеримой.

Проблема в том, что вы не говорите, что такое steam или его роль в вашей системе. По-видимому, хотя между ним и каждым пользователем существует 1-1 взаимосвязь. Так почему бы просто не назовите его ID в таблице пользователя и, при необходимости, ему нужно указать UserID или SteamID в зависимости от того, что имеет больше смысла в контексте, в котором пользователь находится в то время.

При использовании суррогатного ключа, я предпочитаю его назвать ID. Короткие, простые, недвусмысленные. Рассматривая определение таблицы, он говорит: «Я - суррогатный ключ этой таблицы». На самом деле его не путать при использовании одного и того же поля нескольких таблиц в одном запросе. Фактически, это помогает уточнить:

select User.ID, Item.ID, Entry.ID, etc. 
from .... 

Однако запрос устанавливает контекст набора результатов. Aliasing помогает показать, что контекст:

select User.ID as ManagerID, Item.ID OfficeOD, Entry.ID LaptopID, etc. 
from .... 

При его использовании в качестве FK в другой таблице, имя в этой таблице также показать ее использование в контексте установленного этой таблицы. Это особенно удобно, если несколько полей являются ФКС в той же таблице:

table Accounts: 
    ID   the surrogate key to this table...duh! 
    OwnerID references User.ID 
    AdminID references User.ID 
    VerifiedBy references User.ID 

или, возможно,

table Accounts: 
    ID   the surrogate key to this table...duh! 
    SteamID references User.ID 
    AdminID references User.ID 
    VerifiedBy references User.ID