EF CORE 中的 143 个查找表

Question

目前我正在重新设计一个现有的程序，它使用一个包含多个值的主表。(C# .net core 3.0 & EF) (一大查表)

这些值中的大部分很少改变，我会将它们放在 ac# 枚举中。

一些示例：Language、Sex、ReceiptStatus、RiskType、RelationType、SignatureStatus、CommunicationType、PartKind、LegalStatute ……该列表不断增加，目前有 143 个不同的类别，每个类别都有自己的值，其中包含 2 个翻译。

我的公司希望这些值存在于数据库中，因此非程序员可以在必要时更改它们。

不过感觉一点都不好。我很想将表格分开，但创建 143 个表格似乎有点矫枉过正。如果只有 5-10 个查找表，那就没问题了..

有什么建议吗？坚持 1 个查找表？感觉我的眼睛不对。多桌？

说服我的公司我们应该只使用运行良好的 C# 枚举，排除非程序员可以编辑它们的可能性？

Answer 1

根据您使用枚举的倾向，我将假设这些查找值不会经常更改。

系好安全带，因为在下面的分析中嵌入了许多关于可维护性的艰苦奋斗的知识。让我分解您正在考虑的方法：

1. 纯枚举：这是最不灵活的方法，因为它关闭了很多门。正如您所说，更改值需要开发人员和部署。如果您最终有其他表格需要与您的众多价值观之一相关联，那么您的策略是什么？对我来说，这太严格了，特别是因为使用其他任何一种方法，您都可以创建一个 .t4 模板，根据数据生成枚举。然后，如果数据发生变化，您只需重新生成。我经常这样做。
2. 一张巨大的查找表：不像看起来那么灵活！这交换了复杂性、单一责任原则和针对重复​​/表格垃圾邮件的参照完整性，并且可能是 Big Ball of Mud 反模式的一种表达。您可以在此表中添加一列来控制可以使用给定值的位置，这将允许您拥有合理的下拉列表，但这不如参照完整性好。如果其他表需要与查找相关，则必须与整个表相关联，这不太清楚。您必须小心地强制执行您自己的参照完整性层，因为数据库无法帮助您。最后，这是一个大问题，如果您的 143 个值已经或将会有额外的复杂性并且真的可以从额外的列中受益，那么认知负荷就会开始升级。如果 143 个中的 5 个需要它们自己的列，那么您现在必须在脑海中记住所有这五个列才能理解任何一个列……那太痛苦了。如果我没有理解我的观点，这里有一个给你的思想实验：为什么不将整个项目构建为一张巨大的桌子呢？
3. 143张桌子：考虑到所有因素，最灵活的方法最容易维护。它不会关闭任何门；在未来，您仍然可以创建一个 UI 来编辑您想要的任何值。如果您想将其他表与查找值相关联，这种关系将很容易理解，因为您可以与 LegalStatus 而不是 GiantEverythingTable 相关联，并享受参照完整性的好处，而不必担心破坏您自己的数据。您还可以使用 NimbleText（一个很棒的工具和隐藏的宝石）之类的东西编写表和索引创建脚本。会有大量的表，这本身就是一个小维护问题，但它实际上不会破坏任何东西，也不会导致认知负荷。这是一个可以接受的权衡。我会走这条路并使用 t4 生成枚举。

对于任何规模的大多数软件项目，您可能会看到我的反对意见并说它们不适用，而您可能是对的。但是如果这个东西要积极发展，你必须问：你确定吗？你真的知道一年后会发生什么吗？

在考虑权衡时，我学会了为最灵活/最简单的决定分配很多权重。可维护性问题是杀死软件项目的原因。他们是敌人。

希望有帮助！