解释为什么“只需添加另一列到数据库”对于非程序员来说是一个坏主意
我有销售人员和豆制品柜台谁试图出售定制给客户，这很好。 但是当一个复杂的变更请求发回给我一个大的估计时，他们会感到困惑。 他们经常回到我身边：“为什么你不能再添加一列？” 而另一个则是PER客户端的十几个自定义列。
到目前为止，我所能回来的是“我们试图保持数据库正常化”，这对他们来说毫无意义。 我告诉他们，我可以创build一个允许每个客户定义他们自己的一套自定义字段的表格系统，但是当然比“只添加几列”要花费更多的时间和金钱。 当然，他们也想吃蛋糕，也吃。
那我怎么能让他们明白？
我发现的最好的方法是展示如何创build一个新的function ，他们要求你不能只添加几个自定义的列。 function比自定义更好，特别是当你可以向某人收费时。
在进入技术层面之前，试着为你做一个好的商业案例。
我告诉他们，我可以创build一个允许每个客户定义他们自己的一套自定义字段的表格系统，但是当然比“只添加几列”要花费更多的时间和金钱。
我认为你应该把这个选项推给你的老板，因为可定制性显然是一个非常需要的function。 强调为每个客户单独定制（而不是广义的，有限的可定制）系统意味着必须为每个客户创build补丁和更新（导致更长的推出时间和更高的成本）; 非标准化的安装意味着服务台门票需要更长的时间才能closures（导致不满意的客户和更高的成本）; 等等
换句话说，通过显示解决scheme的成本远远超过解决scheme的成本，从而长期获得短期的收益。
销售人员专注于销售。 这是他们的佣金。 他们不关心后面的事情。 然而，老板把重点放在成本上。 卖给你的老板，你的老板可以卖给销售人员。
啊..一点知识是一件危险的事情。
试试这个：
你：我们哪些公司没有卖给？
销售： Acme Industries，OCP Corp，等等等等
你：呃….为什么你不能再打几个电话呢？
答案当然是销售并不那么简单。 软件开发也不是。 除非他们真的想要在架构和维护方面花费数小时的时间，否则我build议他们相信你作为软件开发人员的判断。
这是这里的问题，信任。 你应该向他们解释他们对你的能力缺乏信任。
你可以告诉他们，devise不好的数据库意味着从长远来看：
-
他们需要更长的时间来检索他们的数据 – 他们真的想等待吗？
-
devise查询来生成报告会更困难，花费更长时间 – 如果明天他们需要这个查询，他们是否要告诉他们仍然在工作？
-
这将是一个噩梦维护，容易出错的查询更可能被写入。
如果他们是销售人员和豆制柜台，那么他们一定会明白全能的美元（英镑，欧元等）。 你能否certificate花费在维护这些额外的列上的时间并不能certificate增加的销售额？
在这里要非常小心，确保你的观点是有道理的。 过去，我发现自己对自定义的抵制更多，因为我不想让我漂亮的小领域模型变得丑陋，而不是因为维护起来真的很难。 一个体面的分析将帮助你确定你为什么抵制自定义。
请记住 – 最重要的是你需要保持客户满意度才能保持业务。 我们有思想的开发人员有时会忽视这一点，我们的追求使维护和简单。
Google“技术债务”; 向他们展示结果。
如果您从事的是定制产品的销售业务，则产品需要支持定制化，而不必在每次销售时都分解构build。
听起来像你试图解释说，没有用。 相反，请尝试估算为一张桌子添加“定制正确方式”的成本，例如，维护具有不同定制的六种版本的产品，并修复一个错误。 我敢打赌，他们将会看到，他们很快就会获得统一的代码库和架构。 而且一个开发者不是疯狂的。
告诉他们，当人们制造一辆车，然后他们想要一个比以前更快，更多的模型时，他们通常不会添加另一个引擎。
问题是，“我们试图保持数据库的正常化”几乎肯定是错误的答案 – 它将不信任和交叉目的带回法庭。
你必须把注意力转移到最终目标上，如何才能最好地实现这个最终目标（也许在几个版本中）以及短期和长期的成本。 我已经看到提到技术债务的答案，成本估算应考虑到这些因素。
“只是添加另一列”可能不是一个坏主意？ 你真的没有给出整个商业案例。 另一方面，他们用一个无知的技术问题挑战了你的消极反应。 这并没有达到帮助你理解这个要求的核心，因为他们不喜欢听到“不”。 （我想知道原来的问题是什么。）
使数据库正常化是一个技术问题，与系统必须满足的要求无关 – 这是一个系统devise原则，您可以使用这个原则来交付具有可维护性等特性的系统。 但是一个不能满足用户需求的可维护系统是零价值的，而不可维护的满足用户需求的系统却有非零价值（这可能会超出维护成本 – 这是一个业务问题）。 无论是EAV还是某种其他机制都不是必需的 – 这只会导致系统复杂性或成本增加。
如果要求过于昂贵，那么这就是商业案例的一部分。 您还没有告诉我们足够的关于这些表模型的体系结构或实体的types。 假设你有100个客户。 在特定实体中的列可能有重叠。 多达95％的客户永远不会使用可选的Billing-Address或Middle-Name列，这并不意味着这些列被排除在外 – 不仅如此，他们往往是在一个原始的devise！ 或者，如果这是一个Products表，并且每个客户想要很多特殊的列并且没有重叠，那么您可能需要一个用户定义的现场系统（EAV / XML /标签 – devise必须符合要求）保持一个有凝聚力的系统devise。
我很less发现企业忽视技术债务的论点 – 特别是如果一个提出的解决scheme可以满足用户的需求，灵活性可以成为一个卖点。 我发现，如果您尽可能快速，彻底地提出解决schemeselect，而不花费更多时间解释为什么不能完成某些工作，或者需要花费多less成本，下午，实际上完成了工作。
我从来没有尝试过这个，但我已经想过了：比喻一下法律制度。 存在法律上的漏洞，是因为立法者试图用懒惰的方式来修补这个系统。 软件等同于错误，安全漏洞等等。解决这些问题的唯一方法就是精心策划和努力工作。
让他们了解在开发时间内有多less成本，这个变化是否需要一到两名开发人员的时间？ 那么testing呢？ 如果复杂的请求花费更多，那么整个公司的工作就会减less。 帐户/项目经理应该是缓冲这些types的请求的中间人。
在技术方面，你不会在任何地方向他们解释。 你需要一个比喻。 如果可以的话，将它定制给与你交谈的人。 如果他/她是一个汽车怪胎，让他们思考引擎修改方面。 福特要在金牛座提供三种不同的电动机，还是按需定制MODS，费用多less？
一旦他们接受了比较，即使他们没有完全理解，你也可以开始理解为什么这个比喻是适用的。
还有另外一个很好的方法来帮助他们看到你的方式 – 花一些时间看看它的方式。 当你的薪水取决于给顾客他们想要的东西时，你根本不在意工程中的螺旋桨头是怎么告诉你的。 如果您收到很多自定义请求，则应尽可能考虑采用架构和策略方法来提供这些自定义设置。
为了扩展tuinstoel的build议（避免通用的实体属性值结构）：虽然我一般喜欢这种结构的轻量使用，但过多（无论是什么意思）的使用会降低性能，如上所述。 这样的结构不能很好地索引。 我写了和支持一个这样的系统。 当我们有10万个密钥的50,000个“实体”时，即使在中端硬件上也是很慢的）。
但是，它们非常有用，而且相当容易实施。 因此，如果需要在每个客户的基础上添加许多任意的“额外字段”，那么这可能是最有意义的。
另一个可能的select可能是在适当的表中添加一些未使用的通用列，供客户端用于他们自己的目的。 有些企业应用程序就是这样做的。 销售表可能有十到二十个CUSTCODE01到CUSTCODE10列，每个应用程序的部署可以以不同的，完全自定义的方式使用。
这可能起初看起来很可怕，也可能是一个快乐的媒介。 在每个客户的基础上有相当多的空间可以自定义，而不需要“仅仅添加一列”并且中断应用程序或者开发过程，或者b）实现一个可能很慢的通用系统。 尽pipe如此，您只能获得有限的可用性，并且缺less自我logging的列名（但可根据需要定制列描述）。
…我告诉他们我可以创build一个表格系统，允许每个客户定义他们自己的一套自定义字段，但当然这需要更多的时间和金钱….
看起来你想build立某种通用数据模型？ 实体 – 属性 – 值…？
那些generics模型往往是真正的慢，他们不能正确索引和混淆查询优化。 添加一些列通常会更好。
在走普通路之前做一些非常彻底的基准testing。
也许这是数据库供应商的依赖，但是如果你使用Oracle，我宁愿在实体属性值路上添加一些列。
你可以解释这个问题与图书馆进行比较。 有很多书。 小而厚的，大而薄的，每个人都可以想象得到。 现在，如果你想在某个地方存储更多的信息，将一些新的页面添加到一本书中比放大一些单一的页面要简单很多 – 如果一本书的多个页面比其他页面大，那么这个页面不是很健壮，这个信息是否在索引中没有条目？ 也许最好把新的附加信息存储在另外一本书中，一个新的结构。 想象一下，如果一个图书馆的全部内容都写在一本厚厚的书中，人们如何获得信息呢？ 没有其他人可以find任何东西，直到你find你想要的东西，并把它放回原处。如果你能够携带这本巨大的书。 如果你只想知道一个人的出生date，为什么要检索整个Livestory？
所提到的人不必了解数据库的架构，但他们应该相信你。 而且你组织起来，这样他们就可以把他们的信息放在这个数据库的大洞中，并在需要的时候把它恢复 – 快速而可靠。
