（以防万一：我正在使用 SQLite）
我愚蠢的小数据库有数量惊人的相同结构的表：
CREATE TABLE GTag (
ID INTEGER PRIMARY KEY NOT NULL,
Name TEXT UNIQUE NOT NULL,
Description TEXT
);
回到这里（波兰），它们被称为“字典表”（“tabele słownikowe”）；我找不到合适的英语对应词。它们的作用是提供有限数量的预先确定的选择，通常是下拉框之类的。存储标签似乎是它们设计用来处理的事情。
当我最终确定数据库的结构时，令我震惊的是所有标签和其他类似标签的实体（如“GStatus”、“SStatus”...）都有这 3 个共同的字段，但没有连接到以任何方式彼此。我应该让它们成为更通用的“标签”表的所有子类型吗？
我看到 3 种解决方案来解决我的困境：
- 创建一个具有ID、Name、Description的超类型。除了对应于Key.ID的主ID键（即：是外键）之外，所有当前表都变为 EMPTY 。如果我想查找所有GTag ，我从GTag获取所有 ID ，然后从相应的Tag条目获取数据。然而，子类型并没有给图片带来任何新的东西。它们没有任何字段可以将它们彼此或父类型区分开来。
- 将所有内容转储到一张大Tag超级表中；添加类型字段。因为我从不想要同时来自多个类别的标签，所以所有查询都必须通过类型字段进行过滤。看起来像地狱一样笨重，并且重写非常令人头疼。
- 把事情放在一边就好了。我避免创建具有所有结构但没有共同意义的无用实体。
我的印象是，试图“整理”我的模式最终会导致它陷入混乱，但我没有经验可以坚定地说出来。我在这里错过了什么？每个解决方案提供哪些可能的好处（和缺点）（在性能、整洁度、遵循设计原则方面......），我最终应该实施哪些？