主页 / dba / 问题 / 160279
Accepted
Vestin
Asked: 2017-01-08 09:38:01 +0800 CST

“字典表”的继承

  • 772

（以防万一：我正在使用 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超级表中；添加类型字段。因为我从不想要同时来自多个类别的标签，所以所有查询都必须通过类型字段进行过滤。看起来像地狱一样笨重，并且重写非常令人头疼。
  • 把事情放在一边就好了。我避免创建具有所有结构但没有共同意义的无用实体。

我的印象是，试图“整理”我的模式最终会导致它陷入混乱，但我没有经验可以坚定地说出来。我在这里错过了什么？每个解决方案提供哪些可能的好处（和缺点）（在性能、整洁度、遵循设计原则方面......），我最终应该实施哪些？

sqlite inheritance

1 个回答

  1. Best Answer

    使用一个 supertable Tag会减少模式中的表，但基本上会失去对参照完整性的保证。如果另一个表中的一列必须有一个“颜色”值，则向表“颜色”（您的字典之一）添加引用约束。如果你有一个大的，你可以有一个应该有一种颜色的列有一个值'wide'，因为这个值也在你的字典中，即使它不是一种颜色。

    使用一个超级表，您可以将保证引用完整性的责任从数据库转移到您的应用程序（或中间件）。如果这样做，您应该确保除了通过您的应用程序之外，没有其他方法可以更改数据库中的值。

    我看不到拥有继承层次结构有任何优势。即使您的结构看起来完全相同，但它们的含义却完全不同。您可以在某处获得一些操作优势（例如只有一个过程来执行 Tag 表的“维护”），但我想您可以仅使用表名作为应用程序中某处函数调用或方法的参数来做同样的事情。

    我不太关心性能。拥有许多小的“字典”表（查找表）不会对您造成伤害。

    • 3

相关问题