查找表最佳实践：数据库表…或枚举
如果我们必须存储公司的可用职位（即经理，团队领导，等等）。 存储它的最佳实践是什么？ 我有两个意见与评论…“当然，欢迎你”
- 将其存储为带有列ID和名称的数据库表，并使用查询和连接进行处理。
- 将它作为Enum存储并忘记数据库表。
在我看来，如果我有更改项目，我会select第一个解决scheme。 所以我不会将这些选项硬编码为Enum。
如果我毫不怀疑数据不会改变（例如性别：男性，女性），我可以selectEnum解决scheme。
注意：我用英文编码，UI文化可能是阿拉伯文。 如果我将使用Enum解决scheme，我将在表示层中对基于文化的string进行硬编码，从最佳实践的angular度来看，这样做是否可行！
我想知道你的意见，如果我的想法对应于什么是最推荐的“最佳做法”？
一般来说，只应使用枚举，其中一组清晰的项目不会改变。 男性/女性是一个很好的例子，否则查找表，适当实施的外键几乎总是最好的select。
查找表选项可能有一个可能的变体，您可能有大量查找表用于简单的标识/值关系。 一个域/查找表对可以大大减less所需的表的数量，虽然有一些额外的编码复杂性。 在这种情况下，你需要一个域名表
DomainID int标识 Domain varchar（255）
和一个键/值表
DomainID int ID int标识 值varchar（255）
因此，一行被添加到对应于您将使用的每个查找表的域表中，并将所有（键值域）/值对添加到值表中。 除了简化数据库结构之外，这种方法还具有可以dynamic地在应用程序代码中创build“查找表”的优点，这在某些应用程序中是非常有用的。
我倾向于select数据库选项，因为这使得查询有意义的数据（即名称而不是ID）变得容易。
如果我确信这些值不会改变，那么我将在应用程序中枚举它们，这样当您不必记住一个项目的ID并且使代码更具可读性时，它使开发变得更容易。
这种方法允许我select是否在查询中包含查找表。 例如，我将它包含在一个报表查询中，我希望显示查找值，但是如果我可以从枚举中推断出它，那么在我的应用程序中加载数据时可能不会包含它。
显然，如果值可能会改变或修改枚举可能是不可能的。
只有你可以判断UI文化的影响，我对用户的文化是100％肯定的，所以不必太担心。
选项1：将其存储为带有列ID和名称的数据库表，并且使用查询和连接处理它是您应该执行的最小操作。
从“ 五个简单的数据库devise错误你应该避免 ”：
虽然应用程序强制的完整性有时受到开发人员的青睐，但DBMS仍然必须是所有完整性的集中执行者。
build议的最佳做法是将数据库实现为对用户界面一无所知。 也就是说，数据库应该执行所有关于数据的规则; 在这种情况下，数据库应该执行哪些值是合适的。 为了枚举什么值是合适的，每种查找值的查找表通常是要走的路。 很多时候，应用程序来了又去，但数据库仍然存在并被重用。
如果你想在应用程序中执行枚举，你当然可以这样做，但无论你做什么，都要确保数据库作为一个数据库来完成它的工作，并保持数据的完整性。 如果麻烦的话，麻烦一下。 你正在奠定基础。 在“ 数据库devise与比萨斜塔 ”中，作者强调了为什么在数据库中正确地开展基础工作非常重要。
我希望这有帮助。
我经常使用数据库选项，因为它有几个优点，其中一个主要的优点是可以在查询列表中更改项目的名称/描述，而无需更改任何代码。 也同意有一个单一的表，而不是许多小表，这样你编写一个单一的例程，以检索从数据库中的值减less维护成本。 有一个单一的例程意味着你可以投入更多的努力，使其performance良好。
除了上面的Cruachan的回复之外，如果你有一个父 – 子关系，那么没有父节点的行描述域，你就可以得到一个表。 属于一个域的所有logging都有域行作为其父项。
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
查找，查找，查找（在这里插入猴子跳舞的video）
我个人的 “最佳实践”是在数据库中拥有一切。 在一家公司的职位绝对是一个查询表。
翻译也是如此，这可能有点棘手，但通常将表格与翻译表连接在一起的视图定义是一个好的开始。
此外，如果Position只是一个int值，而您的应用程序是单一语言，则可以将位置标题直接添加到数据库。
我往往总是把这种东西放在桌子上。 如果需要很多，我会caching它。 如果我需要以编程方式引用其中的一些，那么我将创build一个枚举，其值设置为查找项的键值。
例如，代理主键（通常是我的数据访问层可以无形地添加/更新它），项目的值字段以及“候选项”（候选项被引用，因为它不是必需的，所以它是唯一的或null）。 这样我可以使用引号中的枚举引用表中的特定/重要项目，但仍然具有让最终用户添加新项目的灵活性。 所使用的数据模型的具体细节实际上取决于你的偏好（有些人现在可能正在尖叫着我，不仅仅把“候选”字段作为真正的主键）。
你打算把这个雇主名单放在一个数据库里吗？
如果是的话，把它放在一个文件中，并完成它。
数据库是伟大的，但如果你需要一个简单的键值，他们是矫枉过正。 他们给你很多东西。 但是他们在幕后也做了很多事情，他们还需要支持更多的东西……如果你能用一个带有20个制表符分隔的行的文件脱身，那就简单点吧。
如果你有很多事情需要这种查询，或者如果你认为你可能需要在客户端尝试阅读时更新它们，或者以后可能需要交叉引用，那就去DB。
如果你能保持同步，我不认为没有太多的理由不同时拥有。 当我用数据库存储开发一些状态机function时，使得在我的IDE中枚举可用的对象状态变得更容易。
我自己写了一个小小的EnumGenerator Visual Studio Addin，在C＃中从IDE中右边select的数据库平板的ID和DESC列中创build一个Enumeration代码片段。 我还没有发布它，因为这是我第一次和VS Addins一起工作，而且非常垃圾，但是我敢打赌，具有插件/代码生成经验的人可以将这个想法运用起来。
