厳密に言えば、はい、リレーショナル データベースのすべての行には主キー(一意の識別子) が必要です。手っ取り早い仕事をしているなら、それがなくても済むかもしれません。
内部トラッキング ID
一部のデータベースは、明示的に割り当てない場合、内部で主キーを生成します。すべてのデータベースには、各行を内部的に追跡する何らかの方法が必要です。
ナチュラルキー
自然キーは、各行を一意に識別する意味のあるデータを含む既存のフィールドです。たとえば、チームに割り当てられた人を追跡している場合、「person」テーブルに「employee_id」列があるとします。
代理キー
代理キーは、テーブルに追加する追加の列であり、一意の識別子として任意の値を割り当てるだけです。データベース ( Postgresなど) がそのデータ型をサポートしている場合は、シリアル番号 (1、2、3、…) またはUUIDを割り当てることができます。シリアル番号または UUID の割り当ては非常に一般的であるため、ほぼすべてのデータベース エンジンには、そのような値を自動的に作成して新しい行に割り当てるのに役立つ組み込み機能が用意されています。
私のアドバイス
私の経験では、本格的な長期プロジェクトでは、常に代理キーを使用する必要があります。これまで使用したいと思っていたすべての自然キーは最終的に変更されるためです。姓が変わる(結婚するなど)。会社が別の会社に買収されると、従業員 ID が変更されます。
一方、データの単一バッチを分析して一度だけグラフを作成するなど、簡単で汚い仕事をしていて、データにたまたま自然キーがある場合は、それを使用してください。注意: 1 回限りのジョブは、多くの場合、定期的なジョブになる方法があります。
さらなるアドバイス... 管理外のソースからデータをインポートする場合は、インポートに候補キーが含まれていても、独自の識別子を割り当ててください。
複合キー
一部のデータベース エンジンは、複合キーとも呼ばれる複合キー機能を提供します。複合キーでは、テーブル内の 2 つ以上の列を組み合わせて単一の値を作成します。これらの値は、組み合わせると一意であることが証明されます。たとえば、「person」テーブルでは、「first_name」フィールドと「last_name」フィールド、および「phone_number」フィールドは、一緒に考えると一意になる場合があります。2 人が結婚し、同じ自宅の電話番号を共有し、それぞれが同じ姓を持つ「アレックス」という名前になっている場合を除きます。このような衝突や、意味のあるデータが変更される傾向、およびそのような結合された値を計算するオーバーヘッドのため、特別な状況がない限り、単純な (単一列) キーを使用することをお勧めします。