拥有未在数据库中定义的ID的不良做法？

Question

我正在处理其他人编写的应用程序，看起来他们正在整个应用程序中使用未在数据库中定义的ID。举一个简单的例子，假设有一个名为Question的表：

Question
------------
Id
Text
TypeId
SubTypeId

目前，SubTypeId列中填充了一组不引用数据库中另一个表的ID。在代码中，这些SubTypeId被映射到配置文件中的特定字符串。

过去当我有这些类型的值时，我会创建一个查找表并插入适当的值，但在此应用程序中，配置文件中的ID与其对应的文本值之间存在映射。

在配置文件中而不是在数据库本身中定义查找表是不好的做法吗？

Answer 1

  

在配置文件中而不是在数据库本身中定义查找表是不好的做法吗？

当然，是的。它会严重依赖代码来管理和维护引用，获取必要的值等。在您现在需要创建其他功能的情况下，您将依赖于复制粘贴映射（或导入它们等）这更容易引起问题。

这类似于DB约束应该在DB中而不是在访问它的程序/应用程序中 - 任何维护或新应用程序都需要复制所有行为和规则。以这种方式做事有类似的副作用I've mentioned here in another answer。

拥有查找表的充分理由：

1. 由于数据库通常自然具有这些关系，因此使用它们显而易见。
2. 查询首先需要在Type-和SubType- Text vs ID的代码中构造，而不是将它们作为实际执行的查询的where / having子句的一部分。
3. 速度/性能 - 使用正确的索引和表结构，您将从中受益（并降低管理它的代码复杂性）
4. 您无需更新代码即可添加新的Type或SubType，也无需编辑/删除它们。

这样做的可能原因，我认为这不是正当理由：

• TypeID和SubTypeID是相关的，原设计师不知道如何创建复杂的外键。 （虽然不是一个好理由。）
• 另一种可能是“翻译”，但也可以使用外键关系处理。
• 在某些代码段中，可能没有严格的TypeID - 到 - SubTypeID关系，并且逻辑是在代码而不是在DB中处理的。同样，如果可能，可以使用'flag'值或NULL进行管理。这些特定情况可以通过设计数据库权限然后解决代码中的唯一/奇怪情况来处理，而不是将所有依赖性放在代码上。
• NoSQL：原始设计师可能会认为这样的外键或关系不能在NoSQL数据库中完成。
• 显而易见的“人”问题与技术挑战：原始设计师可能没有正确理解数据库，可能是一个程序员谁做了那个应用程序（或制作来做它）没有正确的知识或帮助。
• 只是把它放在那里：如果前任设计师是外部承包商，他可能已经使用代码维护复杂性或“支持”条款作为获得更多业务/资金的手段。

Answer 2

作为一般的经验法则，我会说将所有相关数据保存在数据库中是一种更好的做法，因为它消除了数据库和应用程序之间的默认依赖关系，并且因为它使数据库更加“易于理解”。 “如果SubTypeID的定义在查找表中，则可以创建返回人类可读结果的查询等。

那就是说，正确的答案可能取决于应用程序的具体细节。如果DB和app之间存在非常紧密的耦合（例如，如果DB不会被其他客户端访问），这可能是一个小问题，特别是如果SubTypeID集很小并且很少更改。