sql - 负整数索引 : are they evil?

Question

我有我正在设计的这个数据库。

它需要包含几十个表，其中包含我们提供的记录(一堆默认值)以及用户可以添加的记录。为了不让用户射中自己的脚，有必要不让他修改默认记录。

有很多方法可以促进这一点，但我喜欢为 protected 记录提供负整数索引的想法，同时将 0 保留为无效的记录 id 并为用户记录提供正整数索引。

CREATE TABLE t1 (
    ixt1  integer AUTOINCREMENT,
    d1    double,
    CONSTRAINT pk_ixt1 PRIMARY KEY (ixt1),
    CONSTRAINT ch_zero CHECK (ixt1 <> 0)
);

-2 | 171.3 <- canned record
-1 | 100.0 <- canned record
 1 | 666.6 <- user record

这看起来不错的原因:

它不会使用更多的空间

很容易理解

它不需要很多额外的表来实现

"select * from table"获取所有相关记录，没有额外的间接访问

jar 头记录可以负向增长，用户记录可以正向增长

但是，我对数据库设计比较陌生。在使用这个解决方案一段时间后，我开始担心使用负索引可能不好，因为

不同的 DBMS 可能无法一致支持负索引，这使得编写与数据库无关的代码变得困难

通过在 recid 0

插入一些东西可能太容易搞砸了

使用期望具有非负值的整数索引的工具(可能像 db grids)可能会变得很困难。

也许还有其他一些非常明显的原因会使这成为一个非常糟糕的主意。

那么最终的答案是什么？负整数索引是邪恶的吗？

Answer 1

其中最重要的缺陷是“智能 key ”问题。

负整数作为键工作正常。在所有数据库中。

没有工具需要正整数索引值。

搞砸这件事相对容易，因为指数有一个不明显的“规则”，在你中了彩票离开后，没有人会记得。

此外，当您发明第三个状态代码(“预制 jar 头”与“客户特定 jar 头”与“产品线发明的另一个 jar 头”与“版本 3 之前的旧 jar 头”)时，你注定要失败.

“智能 key ”的问题在于您要求 key 做两项不相关的工作。

它是记录的唯一标识符。这就是 key 应该是什么。

您还要求它提供状态、控制和授权以更改属性。哎呀。这充满了危险。您无法扩展其含义，因为它是一个隐藏在 key 中的位。

只需添加一个带有“所有者”的列。如果它归“神奇的 super 用户”所有，则不会向用户显示。如果您不能相信您的应用程序开发人员会强制执行它，请使用 VIEW 来确保这一点。

如果它归“神奇的 super 用户”所有，那么它就是默认数据，以及适用于该所有权的任何规则。