62

如果我们必须存储公司的可用职位（即经理、团队负责人等）。存储它的最佳做法是什么？我有两种意见和评论......“当然，欢迎你的”

  1. 将其存储为具有列 ID 和 Name 的 DB 表，并使用查询和连接处理它。
  2. 将其存储为 Enum 并忘记数据库表。

在我看来，如果我有更改项目，我会选择第一个解决方案。这样我就不会将这些选项硬编码为 Enum。
如果我确信数据不会改变（例如，性别：男性、女性），我可以选择 Enum 解决方案。

注意：我用英语编码，UI 文化可能是阿拉伯语。如果我将使用 Enum 解决方案，我将在表示层中对基于文化的字符串进行硬编码，从最佳实践的角度来看是否可以！！！！

我想知道您的意见，如果我的想法符合最推荐的“最佳实践”？

4

9 回答 9

47

一般来说，你应该只在有一组明确的不会改变的项目时使用枚举，例如原色或大陆名称。否则，具有适当实现的外键的查找表几乎总是最好的选择。

查找表选项有一个可能的变体，您可能有大量用于简单 id/值关系的查找表。域/查找表对可以显着减少所需的表数量，尽管会增加一些编码复杂性。在这种情况下，您将拥有一个域表

DomainID int 身份
域 varchar(255)

和一个键/值表

域ID int
ID int 身份
值 varchar(255)

因此，在域表中添加了一行，对应于您将使用的每个查找表，并将所有（键域）/值对添加到值表中。除了简化数据库结构之外，这种方法还具有可以在应用程序代码中动态创建“查找表”的优点，这在某些应用程序中非常有用。

于 2009-01-11T20:27:55.817 回答
12

选项 1：将其存储为具有列 ID 和名称的数据库表，并使用查询和连接处理它是您应该做的最低限度。

来自“你应该避免的五个简单的数据库设计错误”：

虽然应用程序强制完整性有时受到开发人员的青睐，但 DBMS 仍然必须是所有完整性的集中执行者，这仍然是事实。

推荐的最佳实践是实现您的数据库，就好像它对用户界面一无所知。也就是说，数据库应该强制执行与数据有关的所有规则；在这种情况下，数据库应该强制执行适当的值。为了枚举哪些值是合适的，每种查找值类型的查找表通常是要走的路。很多时候，应用程序来来去去，但数据库仍然存在并被重用。

如果您想在应用程序中强制执行枚举，您当然可以这样做，但无论您做什么，请确保数据库完成其作为数据库的工作并维护数据的完整性。如果麻烦，就去解决它；你正在奠定基础。在“数据库设计和比萨斜塔”中，作者强调了为什么在数据库中正确地打好基础非常重要。

我希望这有帮助。

于 2013-12-17T16:19:47.153 回答
7

我总是选择数据库选项，因为它有几个优点，其中一个主要优点是您可以更改查找列表中项目的名称/描述，而无需更改任何代码。还同意使用单个表而不是许多小表，这样您就可以编写一个例程来从数据库中检索值，从而降低维护成本。拥有一个单一的例程意味着您可以投入更多的精力来使其表现良好。

除了上面 Cruachan 的回复，如果您有父子关系，其中没有父级的行描述域，您可以使用一张表。属于域的所有记录都将域行作为其父项。

ID           int autonumber -- integer primary key for performance
DomainID     int            -- null for domains
Name         varchar(100)   -- Name of the item
Description  varchar(255)

因此，例如，货币列表可能包含：

 ID    DomainID   Name              Description

 100   NULL       ISO Currencies    List of ISO Currency codes
 101   100        BHD               Bahrain Dinar
 102   100        GBP               British Pound
 103   100        EUR               Euro  
 104   100        USD               US Dollar
于 2009-01-13T17:31:12.740 回答
5

我倾向于选择数据库选项，因为这样可以轻松查询有意义的数据（即名称而不是 ID）。

如果我相当确信这些值不会改变，那么我将在应用程序中枚举它们，并且当您不必记住项目的 ID 并且使代码更具可读性时，它会使开发变得更加容易。

这种方法允许我选择是否在查询中包含查找表。例如，我会将它包含在我想要显示查找值的报告查询中，但如果我可以从枚举中推断它，则在我的应用程序中加载数据时可能不包含它。

显然，如果值可能会发生变化或修改，枚举可能是不可能的。

只有你可以判断 UI 文化的影响，我 100% 确定我的用户的文化，所以不必太担心 :)。

于 2009-01-11T20:08:09.070 回答
4

您打算将这份雇主名单放入数据库中的唯一事情是什么？

如果是，请将其放入文件中，然后完成。

数据库很棒，但是如果您需要一个简单的键值，它们就大材小用了。他们给你很多东西。但他们也在幕后做了很多事情，他们是你需要支持的另一件事......如果你可以摆脱一个包含 20 个制表符分隔行的文件，那就简单一点。

如果您有很多需要此类查找的内容，或者如果您认为在客户端尝试读取它们时可能需要更新它们，或者如果您以后可能想要交叉引用这些内容 - 那么请选择数据库。

于 2009-01-11T21:46:51.133 回答
2

我几乎总是把这种东西放在桌子上。如果需要很多，我会缓存它。如果我需要以编程方式引用其中的一些，我将创建一个枚举，其值设置为查找项的键值。

例如，一个代理主键（通常这样我的数据访问层可以无缝地添加/更新它），一个用于项目值的字段，加上一个“候选人”（候选人在引号中，因为它不是必需的，所以它要么是唯一的或空）。这样，我可以使用引号中的枚举来引用表中的特定/重要项目，但仍然可以灵活地让最终用户添加新项目。使用的数据模型的细节实际上取决于您的偏好（有些人现在可能对我大喊大叫，因为不只是使用“候选”字段作为真正的主键）。

于 2009-01-11T21:35:15.153 回答
2

查找，查找，查找（在此处插入猴子跳舞视频）

我个人的“最佳实践”是将所有内容都保存在数据库中。公司中的职位绝对是一个查找表。

翻译也是如此，这可能有点棘手，但通常将表与翻译表连接起来的视图定义是一个好的开始。

此外，如果 Position 只是一个 int 值，并且您的应用程序是单语言的，您可以将职位标题直接添加到数据库中。

于 2009-01-11T20:14:11.883 回答
2

我一般都喜欢两者。我在 dal 层中使用 table，因为它们可用于 tableau 等工具，用于报告、SQL 查询和其他目的。

我在前端和业务层使用枚举，因为它易于使用它们进行开发，并且您不必从 dal 中获取列表，也不必记住表中的值。

如果表中的列表和枚举中的列表相同，C# 会自动为您将枚举转换为相应的 ID。

在 MVC 中，您可以在视图中使用带有枚举的下拉列表作为 @Html.EnumDropdownListFor()，这样您就不必为下拉列表访问数据库本身。

于 2018-04-17T21:57:19.367 回答
0

如果您可以使它们保持同步，我认为没有太多理由不同时拥有两者。当我使用数据库存储开发一些状态机功能时，在我的 IDE 中枚举可用对象状态变得更加容易。

不久前，我为自己编写了一个小的 EnumGenerator Visual Studio Addin，它从您在 IDE 中选择的 DB Tablet 的 ID 和 DESC 列在 C# 中创建了一个枚举代码片段。我还没有发布它，因为这是我第一次使用 VS Addins，它非常垃圾，但我敢打赌，有插件/代码生成经验的人可以接受这个想法并运行它。

于 2009-03-18T19:09:06.480 回答