假设我有一个客户对象，其中包含所有标准客户属性（名称，地址，联系人等）。我们得到一个新客户（Acme），他们有一个非常具体的要求，我们发送给他们的发票上面有我们的ID作为条形码。我们不希望所有其他客户使用此功能，因此我们打算将此作为Acme的特殊情况。现在，让我们假设许多客户都有这些小的一次性请求。什么是模拟这些数据的最佳方式：
我看到了几种可能性及其好处/权衡：
1）在偏差点硬编码，检查身份证或客户名称
优点：最少的努力，单点集成
权衡：邋code的代码，非常容易出错。修改标志需要新部署。随着属性数量的增加，很难找到偏差。
2）Customer上每个属性的DB列。对于一个客户，标志将设置为true，对于所有其他客户，标志将为false
好处：相对简单，属性可以在飞行中更改
权衡：制作非常广泛的数据库和草率的架构。随着更多属性的添加，数据将变得越来越难以管理。代码也会变得草率，因为需要映射许多不必要的属性。
3）硬编码属性映射。包含客户特殊属性的地图。然后可以为特殊属性请求映射，并且代码流可以从那里发出
好处：单点管理。
缺点：硬编码。客户ID /名称将在代码中。进行更改需要部署。
4）带有键/值列的CustomerProperty表。
好处：干净。单点管理。动态。
缺点：与其他解决方案相比，相对复杂。
显然，选择会因环境而异。如果我们有数百个偏差，那么拥有一个单一的管理点就很重要。如果它真的是一次性的偏差，我认为＃1会没事，虽然是黑客。
我对哪种情况下的最佳情况有自己的看法......但我想知道其他人的意见。
答案 0 :(得分：1)
我会选择选项4.从经验来看，当我选择更快的选项时，结果不可避免地是最佳解决方案的实施，而黑客只会导致问题。我总是尝试从域的角度来处理这些问题，在这种情况下，4是最好的模型。与维护所有工件和最终重构相比，实现的差异很小。
答案 1 :(得分：1)
我在我之前的一个项目中做了很多1），最终转到了像4号这样的解决方案。我用我的黑客的位置放置钩子进行定制。它肯定更容易管理，尤其是随着定制请求的增长。
我原本以为2）可以适用于您的特定场景（不考虑所谓的额外自定义请求，只考虑条形码请求），因为我认为其他客户端最终也可能需要在其发票上使用条形码。但是，我还可以看到他们希望条形码信息的格式与您最初为第一个客户设计的格式不同，因此这可能会导致您遇到的问题。
所以我说4），因此在您的自定义实体和客户实体之间实现多对多关系。最初，自定义entites不应该超过值，以便在应用程序代码中执行switch语句。
答案 2 :(得分：0)
我更喜欢完全标准化的方法;我有一个表，用它的主键枚举不同的一次性特殊请求。然后我有一个连接表，它有两列，都是外键，第一列是客户的id，第二列是特殊请求表中的id。