一个(关系)表＆＃34;超级键＆＃34;是每组在表中具有唯一子行的列集。 (请注意，超级密钥的每个超集也是一个超级密钥。)(简单的SQL KEY声明了什么，以及那些超集。)不包含较小超级密钥的超级密钥是＆＃34;候选密钥＆＃34;。规范化和其他关系理论关注候选键并且不关心主键。就查询，更新和约束的含义而言，没有必要或基础来选择一个候选密钥并将其称为“＃34; primary＆＃34; (和其他人＃34;替代＆＃34;)。它只是从关系模型早期的关系前系统延续下来的传统，当时它并没有被理解为是不必要的。
索引的目的也是不必要的(必须具有性能，另一个重要的可观察表达式)。
然后，因为有一个传统的主键，其他东西(如自动索引)附加到他们身上。但是这些东西并不需要附加到主键上，主键不是那些其他东西所必需的。
SQL只允许你声明一个PRIMARY KEY，因为只有＆＃34;假设＆＃34;成为一个主键，但这并不意味着有充分的理由在附加功能之外声明任何内容。无论如何，SQL PRIMARY KEY实际上意味着UNIQUE NOT NULL，即超级密钥，而不是候选密钥，所以只有在UNIQUE NOT NULL的适当子集上没有声明PRIMARY KEY时才这样做列是它声明一个主键。因此，SQL PRIMARY KEY不一定是主键的事实表明声称对主键的需求是多么空。 (并且SQL FOREIGN KEY不是外键，因为它们不会引用任何但只有候选键(应该如此)，甚至只引用任何但只有主键，或者甚至只引用{ {1}} s，它们只引用任何超级密钥。所以再次说明主键必要性的说法是空的。)
大多数SQL DBMS会自动且特别地索引PRIMARY KEY。但这只是向用户揭示某些实施方式的某种方式。
有时声称，使用单一方式引用核心业务实体可以证明拥有基表主键。但是，任何表表达式的任何超级键，即任何一个候选键的任何超集，都标识任何包含的超级键所做的一切(包括主键)。因此，即使实体的主键列不存在，查询仍然可以具有标识它的列。此外，任何表表达式的任何超级键都标识某个实体，无论它是否在某个基表中被标识(更不用说通过主键)。此外，即使通过查询对列进行了预测/ PRIMARY KEY，其行的含义仍然是根据保存这些列的表的含义。因此，查询，更新或约束可以再次涉及核心业务实体，而不存在其指定的主键列。并且它可以涉及没有关联的基本主键列的派生实体。因此声称主键是必需的或基本的或唯一识别是没有根据的。
