【问题标题】:Warning message for a primary key constraint主键约束的警告消息
【发布时间】:2011-10-18 22:55:29
【问题描述】:

我在其中一个包含员工信息的表中分配主键时遇到问题。该表中没有唯一列,我剩下的唯一选择是将三列组合作为主键。

  1. 但它给出了一个警告消息Warning! The maximum key length is 900 bytes. The index 'pk_hrempid' has maximum length of 1530 bytes.For some combination of large values, the insert/update operation will fail 我开始知道这将是未来插入数据的一个主要问题。这个警告有解决办法吗?

  2. 其他问题是我可以将自动增量值作为唯一 id,是否推荐?我想确保它不会像我一样在未来出现问题许多表包含来自其他部门的员工信息。一些员工可能同时在两个或多个表中

感谢任何帮助!

【问题讨论】:

  • 有兴趣了解导致该错误的列数据类型定义。
  • 很难调试我们看不到的 SQL DDL 代码 ;) 不要害羞,发布属性名称数据类型和示例数据。您可能会在这里找到对您的业务领域具有领域知识的人,他们可以为您指明行业标准密钥或其他受信任的标识符来源的方向。
  • @Widor..谢谢你的线索..我所有的数据类型都有一个默认的 nvarchar(255)(因为我已经从访问中放大了),这对于列中的数据来说太长了,我已经更改了主键列的数据类型,然后主键没有警告!我是否必须更改所有其他列的数据类型(与 nvarchar 相比,这些列的数据也很小)......还是可以按原样放置?

标签: sql primary-key composite-primary-key


【解决方案1】:

虽然从您对复合主键的尝试中听起来您正在尝试使用“自然键”的最佳实践,但使用自动递增的 ID 字段并没有什么“错误”。

如果您建议的字段太大而无法用作键,那么它们可能一开始就不是最佳选择。您能否添加另一个具有更好数据类型的“自然”键列?

不要忘记通过为将被大量查询的表选择好的索引和合适的数据类型来考虑可能的优化。

【讨论】:

  • 我猜你的意思是说,“使用代理键除了自然键没有任何'错误'......”(旁白:我不同意) 但这里的问题是 DBMS 无法强制执行自然密钥。
  • @OTTA 我应该用“如果自然键可行”或“如果自然键适合作为主键”来限定它。也就是说,如果 'natural' 和 'surrogate' 都是小的、数字的和可索引的,那么每次都使用 'natural' 。
  • 感谢大家的建议。如果我将自动增量值作为所有表中所有员工的主键,我认为这会导致混乱......不是吗?
  • @user939615 是的,您只在Employee 表上放置了一个自动增量ID。任何同时引用 ID 的表都将具有相同的数据类型,但不会自动递增 - 并且可能与 Employee 具有 FOREIGN KEY 关系。
【解决方案2】:
  1. 这是主键的限制。 PK 不能大于 900 字节。

  2. 您可以在表中添加一个标识列并将其设置为主键。我更喜欢使用 Guid,因为它们是全球唯一的。

【讨论】:

  • 1.这肯定是 SQL Server 的限制吗? 2. 这不会阻止现有三列中的重复。
【解决方案3】:

我会为主键使用自动增量类型的解决方案,将个人数据用于此类事情的问题是您无法保证唯一性,这是主键的基本要求。

【讨论】:

    猜你喜欢
    • 2014-08-12
    • 1970-01-01
    • 2015-11-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-12-06
    相关资源
    最近更新 更多