0

我正在考虑更改数据库方案以减少表的数量。我有几个表包含不同但相似的数据，我想知道这样保留它是否是最佳实践，或者将它们组合起来是否会有并发症。

例如，假设我有以下两个表：

Table `status`

`status_id` | `status_text`
---------------------------
1           | Open
2           | Closed
3           | On Hold

Table `type`

`type_id`   | `type_text`
---------------------------
1           | Regular Work
2           | Advanced Work
3           | Warranty Work

将这些组合成一个表格是否有利，如下所示？

Table `text`

`id`        | `type`        | `text`
-------------------------------------------
1           | 1             | Open
2           | 1             | Closed
3           | 1             | On Hold
1           | 2             | Regular Work
2           | 2             | Advanced Work
3           | 2             | Warranty Work

该type列将与表示数据集类型的 PHP 常量相关联。

我目前可能有 6 个表格，其中包含此确切方案中的数据。只是让我觉得它们是如此相似，而且每个只有 2-5 行。我真的很想像上面那样将它们结合起来，但不确定在此过程中是否会出现并发症，或者它是否违反了最佳实践。

我确实意识到该id列会发生冲突并且不会成为主键的候选者，但它将是一个唯一键以及type防止冲突。我不担心 auto_increment，因为这些表是手动管理的。

还要记住的另一件事是这些表涉及多个 JOINS。除了在 ON 子句中再添加一个条件之外，我认为它不会使 JOIN 变得更加复杂。

如果这是一个重复的问题，我深表歉意，这似乎是一个很难查找的主题，因为我提出的不是关于选择数据的常见问题，而是方案。

4

4 回答 4

4

不，这不行。您将在正确的数据库设计/规范化方面倒退，并不必要地混淆您的数据。

当然你可以做到这一点，但你会在将来的某个时候后悔这样做。你真的想被问到这样的问题：“嘿 Demonslay335，这个工作类型在文本类型表中是什么文本类型？你能帮我打出来吗？Typey-type type type。”

说一个词足够多次会将其变成胡言乱语，就像对您的数据进行元类型化一样。

于 2013-01-08T22:28:07.107 回答
1

如果你有不同的约束，你应该使用单独的表，即使数据“看起来”相似。

例如，如果查找表是分开的，您可以非常自然地为不同的引用表定义 FOREIGN KEY。

如果你把所有东西都放在同一张桌子上，同样的事情会更难做到。纯粹的声明方式是type沿 FK 迁移，然后在引用表中进行 CHECK 以确保正确的类型。不幸的是，MySQL 不强制执行 CHECK，因此您需要通过触发器或（上帝保佑）应用程序逻辑强制执行正确的类型。

于 2013-01-08T23:13:15.667 回答
0

有利有弊，通常归结为个人喜好。我个人更喜欢多个不同的查找表（因为每个查找表对应于我的域中的不同实体定义，尽管它们由巧合相似的原始类型组成）。由于您陈述的原因，其他人有时更喜欢单个“超级查找”表。

我经常看到的一种方法是有这样的东西：

LookUp
----------
ID
LookUpTypeID
Value
DisplayText
etc.

LookUpType
----------
ID
Name

这提供了一种将查找值组织到单个结构中的相当简单的方法。而且，如果您发现自己想要分离类型以“模仿”不同的表（例如，如果像我这样的开发人员加入您的团队并制造了很多噪音），您始终可以根据类型创建视图并使用查询中的那些。

多个小桌子本质上并没有错。如果它们包含的数据真正意味着不同的东西，那么我认为应该将其分开。域中实体的概念意义远比组成它们的数据类型重要得多。

多个小表对数据库引擎影响不大。它非常优化，您不会通过组合表格来做任何事情。事实上，您可能会发现您的查询随着时间的推移变得更加迟钝。从数据库中查询的数据的含义开始被表中的实现细节所掩盖。您可以通过添加视图以再次在逻辑上分离数据来缓解这种情况，但是如果您发现自己需要这样做，那么为什么首先将其组合起来呢？

于 2013-01-08T22:28:30.880 回答
0

我看不出有任何理由将这些表合并为一张表。

我会考虑的一件事是使用枚举列。如果您有作为外键引用的列，status则将它们设为枚举。然后，您可以完全省去桌子。这导致更简单的模式。然而，它有一些弱点（有些人甚至称它为邪恶）；例如，如果您在多个地方使用相同的枚举，则无法保证所有定义都相同，并且随着数据库的发展，它们存在不同步的风险。尽管如此，我们还是在我们的模式中大量使用它们，并没有真正感受到任何痛苦。

于 2013-01-08T23:53:24.903 回答