我在一个项目中与两位顾问合作。事情是我们达到了这样一个程度，即他们两个都无法达成协议，而且每个人都提供不同的方法。
问题是我们有一个有四个部门的商店，我们希望找到在同一个数据库中处理所有部门的最佳方法。
每个部门销售不同的产品：汽车，船，Jetskies和摩托车。
当在每个部门插入或更新数据时，有一些触发器会被激活，因此不同的工作流程将开始，当添加新车时，需要检查某些要求以及汽车的详细信息。与船完全不同。此外，关于数据，有很多共同的领域，我会说到目前为止只有品牌，颜色，型号和年份，其他一切都是针对每个部门，因为不同的产品以及他们如何使用它们。
顾问一说：
为所有部门创建一个表，并使用一列来标识该行所属的部门，这样您将只有一个触发器，然后在触发器中，您将调用每个部门所需的函数/方法记录类型。
原因：您只有一个表（超过200个字段）和一个触发器，更易于维护。此外，如果您需要报告，您只需要查询一个表并根据记录类型进行过滤。如果您需要报告所有项目，则不需要多个联接。
顾问二说：
为每个分区创建一个表，并为每个表创建一个触发器。
原因：您将拥有较小的表格（每个约50个字段）并且更灵活，您将它们全部分开。如果您想要报告，则需要加入表格，因为您希望包含来自不同地方的数据。
我看到将所有东西放在一个地方的好处，但如果我想扩展或改变任何东西，我会感觉我会随着数据的增长而创建一个野兽表。
另一方面，将它分开看起来更具吸引力，但需要为每个不同的表设置所有内容。
你认为最好的方法是什么？
答案 0 :(得分：2)
你应该听第二个顾问。
问题是，所有的设计都是权衡取舍。您需要评估每种方法的优缺点，并且需要考虑每种设计所带来的风险。
我已经这么做了很长一段时间了，就数据库和软件最佳实践而言，当谈到“时尚”时，我已经看到了一些钟摆来回摆动。
我现在说，流行的智慧是关注点分离天生就是好的。这意味着您应该为每个部门分别保存程序逻辑（触发器代码）。这是有道理的，因为你的逻辑会因产品类型而异，因为它们大多数都有不同的列。
第二点也很重要，因为您在交易系统中的利益应始终以第三范式（或更高，如有必要）开头。有时你可以在没有它的情况下逃脱，但是四种不同类型的具有40个或更多不同属性的对象听起来不像是将所有东西都塞进一张桌子的好候选者。例如，如何跟踪哪些列属于哪种类型的产品？每种产品类型都有一个单独的表，可以使您的支持程序员轻松，简单 - 而且非常重要 - 理解。
与顾问所说的相反，如果一个触发器是一大碗意大利面，或者甚至是四个整齐的，写得很好的子程序与{{{{{ 1}}类型语句。
现在，程序员喜欢短的，原子的，单一用途的函数（在你的情况下是触发器）。
如果有足够的公共数据和常见的业务逻辑，这样做四次看起来很尴尬，那么也许你有一个很好的候选人可以选择超类型/子类型。
答案 1 :(得分：0)
我会说一个
这些都是产品，它的自行车或汽车并不重要。您可以通过RecordTypes和Page layouts控制字段和对象，这将使您免于拥有4个对象，这意味着可能有8个新类（如果它遵循我的模式，它可能高达20+）+所有工作流规则和跨这些新对象的验证规则，维护一个有4个对象但结构完全相同的结构将非常困难。跟踪产品。
如果您决定添加平面等新产品，那么将很容易为此对象添加平面，并且如果需要，代码将能够从那里获取。您肯定需要记录类型来管理每个产品。如果顾问正确地构建它，意味着触发器应该永远不具有任何业务逻辑，那么触发器代码不应该是一个问题，只要遵循所有代码将是可维护的
答案 2 :(得分：0)
我会选择一个。
我假设您拥有大量产品，此列表将来会增长。所有这些都是最终的产品。他们将有一些共同的领域和共同的逻辑。
如果将Process Builder与Invocable类而不是Triggers一起使用，那么在添加新对象时，如果其字段和功能与现有对象相同/相似，则可能只需更改配置。
根据您的许可证类型，配置文件可以访问的不同对象的数量也可能有限制。
Salesforce有一个名为Product的标准对象。它是一个基于记录类型分类的单个对象。
如果不是salesforce，我会采用方法二。根据销售人员的工作方式和它所带来的限制，人们认为这是一个更好，更清洁的解决方案。
答案 3 :(得分：0)
我会说选项2 。
为什么？
（1）我会发现一张200 +列的表更难维护。然后，您还必须公开不需要所述字段的对象的字段。
（2）您还必须在触发器内“隐藏”逻辑，然后决定根据部门类型等执行不同的操作......
（3）选项2涉及更多“脚手架”和单独的对象，但这些对象本身就更小，更易于维护，并且没有明确隐藏逻辑或引起任何歧义。
（4）备选方案2遵守单一责任原则。不是每个人都遵循这一点我理解，但我发现它是一个很好的指导原则，因为数据的责任在于个别表，触发动作的责任在于单独的触发，而不是仅仅是一个庞大的实体/触发器。 / p>
**我会说我只是从软件开发的角度来看这个，我不确定SalesForce是否会处理这个设置，但这是我个人更喜欢设计它的方式。 ：）
答案 4 :(得分：0)
选项2对我来说。
你说过几乎没有共同的数据，触发逻辑完全不同。以下是一些额外的技术考虑因素。
选项1警告
触发器将是单点故障，并且调试错误将更加棘手。我曾经使用过大型触发器，其中靠近顶部的破坏逻辑已经停止了靠近底部的逻辑运行，有时甚至是静默！您还必须维护条件保护，以根据数据控制逻辑流，这是另一个出错的机会。
我对索引并不热，但我相信由于多用途数据没有自然顺序，性能会受到影响。更具体的表格将产生更好的索引策略。此外，大行可能导致碎片索引。
在对与所涉及产品无关的每个剩余字段设置可空/默认约束时，需要额外考虑。这些细微之处可能会引入错误，如果/当您决定使用实体框架等数据层技术时，可能会更难。例如。 NULL，0和'None'之间的逻辑差异，特别是在共享列上。