marsisalie's questions

我正在为客户处理的一个 sql 数据库是用一种不寻常的结构创建的。

例如，不要为以下各项设置一个表：

• 国家，

• 状态，

• 城市，

• 单位（英寸、米、英里/小时）、

他们只有两张桌子：

1. 一个用于列表 ID（字段：列表索引和列表名称）。记录前：城市，单位
2. 一个用于给定列表中的项目（字段：项目索引、列表项的描述和引用上述相关列表索引的 fk）。记录前：km/h、亚特兰大、英里、巴黎

listitem 表中 id 的序列是这样组织的，以便在一定程度上将 listitem 中不同组的项目分开，以防需要在列表中添加新项目：

• Unit 的 Seq 可能从 20000 开始

• 城市序列可能从 30000 开始

因此，如果需要添加 10 个新单位，则索引可以与其他已创建的单位保持分组，而不会在其他项目（如城市）中溢出。应用层处理每组项目的序列范围。

他们在列表表中有 30 多个这样的列表，并且在项目表中有数千个项目，每个项目都与列表 ID 相关。

我认为这是没有意义的，原因有很多。但他们认为这很有效，因为“我们只有 2 张桌子而不是 30 张桌子”。他们还认为这是一种新颖且有点典型的工作方式。我知道这在技术上是可行的，但我预计这两个表的实现会出现不必要的和多重问题。

我的问题：做上述事情是典型的还是公认的做法？

我最近开始使用的一个数据库设计有一个包含所有可能值的主表，而其他表中的外键指定了每个项目的性质。

CREATE TABLE entity
(
     indexid INTEGER PRIMARY KEY NOT NULL,
     entitytype INTEGER,
     entityname VARCHAR,
);

例如，这个主表包含一个名为“entityname”的字段，可能包含以下记录：

• 商品的upc代码
• 项目的简称
• 项目的长名称
• 物品的位置
• 此项目的供应商
• 库存数量
• （和许多其他人）

该表中的每条记录都有一个实体类型编号作为外键，在另一个表中引用每条记录的含义，例如

entitytype=10 表示这个实体是UPC码类型，然后

entitytype=12 表示该实体是供应商名称类型等...

显然，实体有十几种这样的类型。

我觉得有点不直观。这里有这篇文章（参见一个表格来保存所有域值部分），作者建议我在示例中表达的方法可能不是最好的方法，我倾向于同意他对事情。

我也认为很难进行有效的查询，我觉得这不是应该这样做的。我宁愿有更多的表格并保持整体更直观。我有一个时间窗口可以重新设计它，并且正在考虑长期和最佳实践。

那么从长远来看，这种方法可以被认为是一种好的做法，而我只需要处理它吗？