EF CORE 中的 143 个查找表
143 lookup tables in EF CORE
目前我正在重新设计一个现有程序，该程序使用包含多个值的主程序 table。 (C# .net core 3.0 & EF) (一次大查找 table)
这些值中的大部分很少更改，我会将它们放在 c# 枚举中。
一些示例：语言、性别、ReceiptStatus、RiskType、RelationType、SignatureStatus、CommunicationType、PartKind、LegalStatute ...
这个列表还在继续，目前有 143 个不同的类别，每个类别都有自己的值，其中有 2 种翻译。
我的公司希望将这些值存储在数据库中，这样非程序员也可以在需要时更改它们。
不过感觉一点都不好。我很想将 table 分开，但创建 143 个 table 似乎有点矫枉过正。如果只是 5-10 次查找 tables 就好了..
有什么建议吗？坚持 1 次查找 table？感觉眼睛不对。多个 tables?
说服我的公司我们应该只使用工作得很好的 C# 枚举，排除非程序员可以编辑它们的可能性？
根据您使用枚举的倾向，我假设这些查找值不会经常更改。
系好安全带，因为下面的分析中嵌入了很多关于可维护性的艰苦知识。让我分解一下您正在考虑的方法：
- 纯枚举： 这是最不灵活的方法，因为它关闭了很多门。正如您所说，更改值需要开发人员和部署。如果您最终有其他 table 需要与您的众多价值观之一相关联，您的策略是什么？对我来说，这限制太多了，特别是因为使用其他任何一种方法，您都可以创建一个 .t4 模板来生成
基于数据的枚举。然后，如果数据发生变化，您只需
再生。我经常这样做。
- 一次巨大的查找 table: 并不像看起来那么灵活！这用复杂性、单一责任主体和参考完整性来对抗 repetition/table 垃圾邮件，并且可能是 Big Ball of Mud 反模式的一种表达。您可以向此 table 添加一列来控制给定值的使用位置，这将允许您拥有合理的下拉列表，但这不如参照完整性好。如果其他 table 需要与查找相关，则您必须与整个 table 相关，这不太清楚。由于数据库无法帮助您，因此您必须小心执行自己的参照完整性层。最后，这是一个大问题，如果您的 143 个值已经或将会有额外的复杂性并且可以真正从额外的列中受益，那么认知负荷就会开始升级。如果 143 个中的五个需要它们自己的专栏，那么您现在必须在脑海中记住所有五个专栏才能理解任何一个专栏……那是痛苦的。如果我没有理解我的观点，这里有一个思想实验供您参考：为什么不将您的整个项目构建为一个巨人 table?
- 143 tables: 最灵活的方法，考虑到所有因素，最容易维护。它不会关闭任何门；以后您仍然可以创建一个 UI 来编辑您想要的任何值。如果您想将其他 table 与查找值相关联，这种关系将很容易理解，因为您可以与 LegalStatus 相关联而不是 GiantEverythingTable，并享受参照完整性的好处，而不必担心破坏您自己的数据。您还可以使用 NimbleText（一个很棒的工具和一个隐藏的 gem）之类的脚本 table 和索引创建。会有大量的 tables，这本身就是一个小的维护问题，但它实际上并没有破坏任何东西，也不会导致认知负担。这是一个 acceptable 权衡。我会这样做并使用 t4 生成枚举。
关于任何规模的大多数软件项目，您可能会看到我的反对意见并说它们不适用，而您可能是对的。但是如果这个东西要积极开发，你必须问：你确定吗？你真的知道一年后会发生什么吗？
在考虑权衡取舍时，我学会了为最 flexible/simple 的决定分配很多权重。可维护性问题会扼杀软件项目。他们是敌人。
希望对您有所帮助！
目前我正在重新设计一个现有程序，该程序使用包含多个值的主程序 table。 (C# .net core 3.0 & EF) (一次大查找 table)
这些值中的大部分很少更改，我会将它们放在 c# 枚举中。
一些示例：语言、性别、ReceiptStatus、RiskType、RelationType、SignatureStatus、CommunicationType、PartKind、LegalStatute ... 这个列表还在继续，目前有 143 个不同的类别，每个类别都有自己的值，其中有 2 种翻译。
我的公司希望将这些值存储在数据库中，这样非程序员也可以在需要时更改它们。
不过感觉一点都不好。我很想将 table 分开，但创建 143 个 table 似乎有点矫枉过正。如果只是 5-10 次查找 tables 就好了..
有什么建议吗？坚持 1 次查找 table？感觉眼睛不对。多个 tables?
说服我的公司我们应该只使用工作得很好的 C# 枚举，排除非程序员可以编辑它们的可能性？
根据您使用枚举的倾向，我假设这些查找值不会经常更改。
系好安全带，因为下面的分析中嵌入了很多关于可维护性的艰苦知识。让我分解一下您正在考虑的方法：
- 纯枚举： 这是最不灵活的方法，因为它关闭了很多门。正如您所说，更改值需要开发人员和部署。如果您最终有其他 table 需要与您的众多价值观之一相关联，您的策略是什么？对我来说，这限制太多了，特别是因为使用其他任何一种方法，您都可以创建一个 .t4 模板来生成 基于数据的枚举。然后，如果数据发生变化，您只需 再生。我经常这样做。
- 一次巨大的查找 table: 并不像看起来那么灵活！这用复杂性、单一责任主体和参考完整性来对抗 repetition/table 垃圾邮件，并且可能是 Big Ball of Mud 反模式的一种表达。您可以向此 table 添加一列来控制给定值的使用位置，这将允许您拥有合理的下拉列表，但这不如参照完整性好。如果其他 table 需要与查找相关，则您必须与整个 table 相关，这不太清楚。由于数据库无法帮助您，因此您必须小心执行自己的参照完整性层。最后，这是一个大问题，如果您的 143 个值已经或将会有额外的复杂性并且可以真正从额外的列中受益，那么认知负荷就会开始升级。如果 143 个中的五个需要它们自己的专栏，那么您现在必须在脑海中记住所有五个专栏才能理解任何一个专栏……那是痛苦的。如果我没有理解我的观点，这里有一个思想实验供您参考：为什么不将您的整个项目构建为一个巨人 table?
- 143 tables: 最灵活的方法，考虑到所有因素，最容易维护。它不会关闭任何门；以后您仍然可以创建一个 UI 来编辑您想要的任何值。如果您想将其他 table 与查找值相关联，这种关系将很容易理解，因为您可以与 LegalStatus 相关联而不是 GiantEverythingTable，并享受参照完整性的好处，而不必担心破坏您自己的数据。您还可以使用 NimbleText（一个很棒的工具和一个隐藏的 gem）之类的脚本 table 和索引创建。会有大量的 tables，这本身就是一个小的维护问题，但它实际上并没有破坏任何东西，也不会导致认知负担。这是一个 acceptable 权衡。我会这样做并使用 t4 生成枚举。
关于任何规模的大多数软件项目，您可能会看到我的反对意见并说它们不适用，而您可能是对的。但是如果这个东西要积极开发，你必须问：你确定吗？你真的知道一年后会发生什么吗？
在考虑权衡取舍时，我学会了为最 flexible/simple 的决定分配很多权重。可维护性问题会扼杀软件项目。他们是敌人。
希望对您有所帮助！