如何处理数据库和应用程序中的“类型”字段？答案

【问题标题】：How to handle "Type" field in DB and app?如何处理数据库和应用程序中的“类型”字段？
【发布时间】：2011-03-07 09:53:15
【问题描述】：

有必要实现日志记录，消息计划存储在数据库中的“日志”表中。在其他字段中，每条消息都会有一个“状态”字段：0 - 成功，1 - 错误数据，2 - 错误用户，3 - 随便，4 - 等等...

简单的想法是将“状态”字段作为“int”列存储在同一个表中...要在表中推送数据，将创建特殊的枚举，类似于这样（例如，让我们使用 C#.NET，但是任何语言都可以）：

enum LogStatusEnum
{
    Successful=0,
    WrongData=1,
    WrongUser=2,
}
void main()
{
    LogStatusEnum status = LogStatusEnum.Successful;
    int statusValue = (int)status;
    string query = "INSERT INTO log (Status, ...) VALUES ("+statusValue+",...)";
}

还有另一种方法：创建附加表，例如“log_status”，其中包含字段“StatusId”（int，autoincrement）、“StatusCode”（varchar）、“StatusDescription”（varchar），其中包含单独的记录每个状态字段（两个表都应用了一个外键）。在这种情况下，在将数据添加到“日志”表之前，应使用查询提前获取所需“代码”的 ID：

query = "SELECT Id FROM LogStatus WHERE StatusCode='"+GetStatusCode(status)+"'";

这个（接收到的）ID 将用于填充“日志”表。

在这两种情况下，您都需要在数据库端和应用程序端保持同步。但从我的角度来看，第二种方法要好一些：

更安全：您需要确保您的“状态”确实存在于数据库在添加数据之前，您将拥有一个约束（错误的状态不会是添加）。
更多数据驱动（很难说对我来说为什么它更好，但我填写那个）。

为了获得这些好处，您需要支付：向 DB 执行请求以通过状态代码获取状态 ID。

您认为实施第二种方法是否合理？还是第一个也适合？您是否看到第二种方法的其他优点或第一种方法的缺点？

欢迎提出任何想法。

提前谢谢你。

【问题讨论】：

标签： c# .net database-design architecture

【解决方案1】：

第二种方法通常更好。如果您需要一个新的状态类型，您只需要更新数据库而不是应用程序代码中的数据结构。

如果你做了很多插入，你不应该每次都查询状态id，而是缓存它。

【讨论】：

另外，可能还有其他应用程序或内部数据库作业需要数据。您可能希望将这些值放在 SSIS 包（或其他一些 ETL 程序）中，而不仅仅是应用程序。
缓存多个插入 - 这很清楚，当然。但是，如果您要添加新的状态类型，您还需要在应用程序端支持它。可能数据结构是相同的，但您至少需要 a) 添加新的代码名称（以获取其 ID）； b) 添加处理新代码名称的功能。

【解决方案2】：

假设数据库中的日志状态是相当静态的，我会设置应用程序在启动时将它们全部加载到本地缓存中，这样您就不必一直加载它们。

如果可能，我自己喜欢第二种方法。除非您在很难获得批准手动更改表中的数据以添加更多状态等的地方工作。

【讨论】：

【解决方案3】：

我会在数据库中定义状态代码，虽然 int 字段可以，但 Char(4) 会更好，因为代码将是人类可读的 - 而且 - 你应该还要指定描述；

“OK__”、“操作按计划进行”
“WUSR”、“错误的用户”
“WDAT”、“错误数据”

使用数字但在数据库中没有描述的问题在于，如果您不知道代码是否同步，或者首先知道代码是什么，您就无法报告它。从长远来看，将它们放在一起将使生活更轻松 - 请牢记Common Reuse Principle。

使描述尽可能有用。从内存中，在 MS SQL 中 Char(4) 使用与 int 相同的空间量 - 因此您不会通过使用 char 来使用额外的空间。

我肯定不会让 ForeignKey 用于在外部将代码识别为自动递增的数字；如果值变得不安，您将失去代码的完整性。

如果您要将状态代码硬编码到应用程序中，我建议您提供一种方法，让人们无需查看源代码即可访问代码；文档可能会削减它，但很容易不同步 - 你想要的是任何人（如管理员 / DBA）都可以轻松调用的某种可调用接口（UI、Web 服务等）。 Attributes 是一个很好的方法。

对于一般参考（或预构建的实现），我强烈建议查看MS Enterprise Libraries，这包括一个日志记录块，还包括一个数据库存储库。

【讨论】：