我是CRM 2013的新手，我一直在阅读和观看很多关于这个主题的视频。我希望有人在互联网上提供一些技巧或建议，这些建议和建议会与我解释和理解这些材料的方式产生共鸣。
我有一个常规的MS Access数据库，有几个不同的表用于存储人事记录。从我迄今所学到的东西来看，CRM看起来是远离Access和CRM的良好候选者。
我的问题是，在收集需求和扩展CRM 2013环境时，有哪些最佳实践？
即。 （为简单起见）
MS Access db有两个表。
每个表都应该有自己的实体（Table_A 1：N，Table_B N：1），还是有时候应该在一个实体下组合多个表？
将所有内容放在一个实体下是否被视为不良形式？
业务流程似乎让我想起了SharePoint工作流程。你什么时候应该依赖BP？
我希望这是有道理的，我仍然试图理解这一切。感谢任何帮助，谢谢！
答案 0 :(得分：0)
Dynamics CRM由SQL Server支持，因此请考虑SQL表以及哪些更好。在大多数情况下，拆分成具有单一责任的较小对象更好，但这可能会影响连接记录的性能。老实说，我们正在远离云中的CRM，因为它不可扩展，不可靠（如果它下降你需要等待它上升 - 没有第二个副本），无法控制底层SQL数据或SQL Server实例大小（DTU） ，很难测试，并且只是一个大项目的痛苦。我们将用代码替换所有业务流程，因为它们也不可测试 - 您无法编写单元测试。
答案 1 :(得分：0)
尽管@seseSemenov有一些好处，但你必须开始CRM的目标。 CRM是一个客户关系管理套件，建立在RADr，快速应用程序开发平台Xrm之上。
Xrm并非旨在成为世界上最灵活，性能最高的平台。如果您的应用需要使用速度以及使用任何特定技术/服务器拓扑来满足您的需求的能力，请不要从XRM开始。
如果开发速度快，上市速度快，开发人员需要开发人员在自定义应用程序开发环境中工作，或者甚至希望在第1天进入云端，那么开发速度更快，价值更高，然后是Xrm，因此CRM是一个很好的起点。
就你的问题而言，一切都取决于你。您的数据标准化程度越高，每个关系的多个实体，确保它们全部同步所涉及的工作就越少，但通常对最终用户处理信息的难度就越大。他们必须导航到多个表单以进行数据输入，并且需要在报告中配置大量连接。
我通常会尽量将数据保持标准化，但如果有任何关系是1：1，请将其合并为单个实体。或者你知道它会成为1：2或1：3的关系（例如，查看联系人和帐户的地址）
基本上，这是一个需要独特审视应用程序要求和个人经验的答案。我强烈建议寻求具有CRM经验的顾问。平台的另一个优点是，有一个完整的开发人员资源池，以及已经了解该框架的BA，并且可以在第一天为业务提供价值，而不是花费2到3周的时间来加速您的特定架构。
祝你好运！