0

我正在开发其他人编写的应用程序，似乎他们在整个应用程序中使用了未在数据库中定义的 ID。对于一个简化的示例，假设有一个名为 Question 的表：

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

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

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

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

4

2 回答 2

1

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

绝对没错。它严重依赖代码来管理和维护引用、获取必要的值等。在您现在需要创建附加功能的情况下，您将依赖复制粘贴映射（或导入它们等）这更有可能导致问题。

这类似于为什么数据库约束应该在数据库中而不是在访问它的程序/应用程序中 -任何维护或新应用程序都需要复制所有行为和规则。以这种方式处理事情有类似的副作用，我在另一个答案中提到过。

有一个查找表的充分理由：

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

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

  • TypeIDand是相关的SubTypeID，原始设计者不知道如何创建复杂的外键。（虽然不是一个很好的理由。）
  • 另一个可能是“翻译”，但也可以使用外键关系来处理。
  • 在某些代码中，可能没有严格的TypeID关系SubTypeID，并且该逻辑是在代码中而不是在数据库中处理的。同样，如果可能，可以使用“标志”值或 NULL 进行管理。这些特定情况可以通过设计正确的数据库来处理，然后解决代码中的独特/奇怪情况，而不是将所有依赖都放在代码上。
  • NoSQL：原始设计者可能认为这样的外键或关系不能在 NoSQL 数据库中完成。
  • 以及明显的“人”问题与技术挑战：最初的设计者可能对数据库没有正确的理解，并且可能是在没有正确知识或帮助的情况下执行该应用程序（或被迫执行该应用程序）的程序员。
  • 只是把它放在那里：如果以前的设计师是外部承包商，他可能已经使用代码维护复杂性或“支持”条款作为获得更多业务/资金的手段。
于 2013-03-05T04:25:41.750 回答
0

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

也就是说，正确的答案可能在一定程度上取决于应用程序的具体情况。如果数据库和应用程序之间的耦合非常紧密（例如，如果数据库不会被其他客户端访问），这可能是一个次要问题，尤其是在 SubTypeID 集很小且很少更改的情况下。

于 2013-03-04T22:17:09.850 回答