すでに一意のキーがある場合、別の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 

または私はまだFlask-SQLAlchemy's examplesに見られるようなユニークなidを含める必要があります。

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が近くにあり、その差異がIDの中のスペースかそのようなものであれば問題になる可能性があります。 uniqueIdを使用するのが本当に最善の方法です。

Answer 3

ID値の数値がシステムによって並べ替えて検索するのが少し速いのは間違いありませんが、その違いは目立つことはありません。

問題は、蒸気が何であるか、またはあなたのシステムでどのような役割を果たすのかを言っていないということです。どうやら、それと各ユーザーとの間には1対1の関係があります。だから、それをIDとUserテーブルで呼び出し、必要に応じてUserIDまたはSteamIDにエイリアスすると、その時点でユーザーの状況にどのような意味があるかによって異なります。

サロゲートキーを使用する場合は、IDと呼ぶことをお勧めします。短く、シンプルで、曖昧ではない。テーブルの定義を見ると、「私はこのテーブルの代理キーです」と書かれています。同じクエリで複数のテーブルの同じフィールドを使用すると、混乱することはありません。実際には、

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

ただし、クエリは結果セットのコンテキストを確立します。エイリアシングは、そのコンテキストを示すのに役立ちます：

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