如何访问Dynamics CRM中的数据？
就平台速度和在 Dynamics CRM 4 上访问数据（只读）的可维护性而言，最佳方法是什么？我已经完成了这三个任务，但对人群的意见感兴趣。
- 通过 API
- 直接通过 Web 服务
- 通过数据库调用视图
...为什么？
我的想法通常集中在数据库对视图的调用上，但我知道那里有纯粹主义者。
What is the best way in terms of speed of the platform and maintainability to access data (read only) on Dynamics CRM 4? I've done all three, but interested in the opinions of the crowd.
- Via the API
- Via the webservices directly
- Via DB calls to the views
...and why?
My thoughts normally center around DB calls to the views but I know there are purists out there.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
考虑到这两个要求，我想说你想调用视图。正确设计的 SQL 查询将会飞速发展。
如果您打算修改数据，则需要使用 API，但这并不是最快的方法，因为它不允许深度加载实体。例如，如果您想查看客户及其订单，则必须单独加载它们，然后手动加入它们。 SQL 查询已经连接了数据。
没关系，TDS 流比 API 和 API 使用的 SOAP 消息更有效。网络服务。
更新
我应该指出关于视图和 CRM 数据库的一般情况：CRM 不会优化自定义实体的表或视图上的索引（怎么可能？）。因此，如果您有一个始终按目的地查找的卡车实体，则需要为该属性添加索引。根据您的应用程序，它可能会对性能产生巨大的影响。
Given both requirements I'd say you want to call the views. Properly crafted SQL queries will fly.
Going through the API is required if you plan to modify data, but it isnt the fastest approach around because it doesnt allow deep loading of entities. For instance if you want to look at customers and their orders you'll have to load both up individually and then join them manually. Where as a SQL query will already have the data joined.
Nevermind that the TDS stream is a lot more effecient that the SOAP messages being used by the API & webservices.
UPDATE
I should point out in regard to the views and CRM database in general: CRM does not optimize the indexes on the tables or views for custom entities (how could it?). So if you have a truckload entity that you lookup by destination all the time you'll need to add an index for that property. Depending upon your application it could make a huge difference in performance.
我将补充杰克的评论，说直接查询表而不是视图（*base & *extensionbase）会更快。
按速度顺序排列是：
I'll add to jake's comment by saying that querying against the tables directly instead of the views (*base & *extensionbase) will be even faster.
In order of speed it'd be:
直接表更新：
我不同意 Jake 的观点，即所有更新都必须通过 API。正确的说法是通过 API 是唯一支持的更新方式。事实上，在很多情况下，直接修改表是最合理的选择：
在系统不运行时一次性导入大量数据。
跨大量数据修改特定字段。
我同意这种直接修改应该只是当 API 的性能不可接受时的最后手段。但是，如果您想要修改数千条记录的布尔字段，对表进行直接 SQL 更新是一个不错的选择。
相对速度
就相对速度而言，我同意 XVargas 的观点。
未过滤的视图与表：我还没有发现性能优势值得手动连接基表和扩展表的麻烦。
未过滤视图与过滤视图：我最近正在处理一个复杂的查询，使用过滤视图运行大约需要 15 分钟。切换到未过滤的视图后，该查询运行了大约 10 秒。查看各自的查询计划，原始查询有 8 个操作，而针对过滤视图的查询有 80 多个操作。
未过滤的视图与 API：我从未将通过 API 查询与查询视图进行比较，但我比较了通过 API 写入数据与直接通过 SQL 插入数据的成本。通过 API 导入数百万条记录可能需要几天的时间，而使用插入语句的相同操作可能需要几分钟的时间。我认为读取期间差异没有那么大，但可能仍然很大。
Direct table updates:
I disagree with Jake that all updates must go through the API. The correct statement is that going through the API is the only supported way to do updates. There are in fact several instances where directly modifying the tables is the most reasonable option:
One time imports of large volumes of data while the system is not in operation.
Modification of specific fields across large volumes of data.
I agree that this sort of direct modification should only be a last resort when the performance of the API is unacceptable. However, if you want to modify a boolean field on thousands of records, doing a direct SQL update to the table is a great option.
Relative Speed
I agree with XVargas as far as relative speed.
Unfiltered Views vs Tables: I have not found the performance advantage to be worth the hassle of manually joining the base and extension tables.
Unfiltered views vs Filtered views: I recently was working with a complicated query which took about 15 minutes to run using the filtered views. After switching to the unfiltered views this query ran in about 10 seconds. Looking at the respective query plans, the raw query had 8 operations while the query against the filtered views had over 80 operations.
Unfiltered Views vs API: I have never compared querying through the API against querying views, but I have compared the cost of writing data through the API vs inserting directly through SQL. Importing millions of records through the API can take several days, while the same operation using insert statements might take several minutes. I assume the difference isn't as great during reads but it is probably still large.