当前，我正在重新设计一个使用包含多个值的主表的现有程序。 （C＃.net core 3.0和EF）（一张大查找表）
这些值中的大多数很少更改，我将它们放在c＃枚举中。
一些示例：语言，性别，收货状态，RiskType，RelationType，SignatureStatus，CommunicationType，PartKind，LegalStatute，...
该列表不胜枚举，目前有143个不同的类别，每个类别都有自己的值，其中包含2种翻译。
我的公司希望将值保存在数据库中，因此非程序员可以在必须时更改它们。
但是感觉并不好。我很想将表分开，但是创建143个表似乎有点过头了。如果只有5到10个查询表，那就没问题了。
有什么建议吗？坚持使用1个查询表？感觉错了我的眼睛。多张桌子？
说服我的公司，我们应该只使用效果很好的C＃枚举，排除非程序员可以编辑它们的可能性吗？
1 个答案:
答案 0 :(得分：3)
根据您倾向于使用枚举，我将假设这些查找值不会经常更改。
请多加注意，因为下面的分析中嵌入了许多关于可维护性的艰苦努力。让我分解一下您正在考虑的方法：
- 纯枚举：这是最不灵活的方法，因为它关闭了很多门。如您所说，更改值需要开发人员和部署。如果最终还有其他表需要与众多价值之一相关联，那么您的策略是什么？对我来说，这太过严格了，特别是因为使用其他方法之一，您都可以创建一个.t4模板来生成
根据数据进行枚举。然后，如果数据发生变化，您只需
再生。我经常这样做。
- 一个巨大的查询表：看起来不那么灵活！这以复杂性，单一责任主体和参照完整性来抵制重复/表式垃圾邮件，这可能是“泥泞大球”反模式的一种表达。您可以在此表中添加一列，该列控制可以使用给定值的位置，这将使您拥有健全的下拉列表，但是这不如参照完整性。如果其他表需要与查找相关，则必须与整个表相关联，这不太清楚。由于数据库无法帮助您，因此必须谨慎执行自己的引用完整性层。最后，这很重要，如果您的143个值具有或将要具有额外的复杂性，并且真的可以从附加的列中受益，那么这将是一个很大的问题，认知负担开始增加。如果143个中的五个需要自己的列，那么现在您必须牢记所有五个列才能理解任何一个列...那是痛苦的。如果我不明白我的意思，这是一个思想实验：为什么不将整个项目构建为一张大桌子？
- 143个表：最灵活的方法，考虑了所有因素，最容易维护。它不会关闭任何门；您仍然可以创建一个UI来编辑所需的任何值。如果要将其他表与查找值相关联，则这种关系将很容易理解，因为您可以与LegalStatus而不是GiantEverythingTable相关联，并享受引用完整性的好处，而不必担心损坏自己的数据。您还可以使用诸如NimbleText（一种出色的工具和一个隐藏的gem）之类的脚本来编写表和索引。会有大量的表，这本身就是一个较小的维护问题，但是它实际上并没有破坏任何东西并且不会导致认知负荷。这是一个可以接受的折衷方案。我会走这种方式，并使用t4生成枚举。
关于任何规模的大多数软件项目，您可能要看我的反对意见并说它们不适用，您可能是对的。但是，如果这件事正在积极开发中，那么您必须问：确定吗？您真的知道一年会发生什么吗？
在考虑取舍时，我学会了为最灵活/最简单的决策分配很多权重。可维护性问题是杀死软件项目的原因。他们是敌人。
希望有帮助！