我正在研究将基于 SQL 的胖客户端 Delphi 应用程序迁移到多层瘦客户端,并且一直在研究在 Delphi 2010 中使用 Datasnap。我已经阅读了 Bob Swart 编写的白皮书并进一步扩展了这一点。
我的主要问题确实是,由于多个查询正在运行并同时保持打开以询问数据,我希望在连接和 SQL 查询方面提高服务器端效率,任何人都可以为我指明方向以获取有关如何进行的指导设计一个真实世界的 Datasnap Server 应用程序,因为演示的细节不够详细。
谢谢马特
我正在研究将基于 SQL 的胖客户端 Delphi 应用程序迁移到多层瘦客户端,并且一直在研究在 Delphi 2010 中使用 Datasnap。我已经阅读了 Bob Swart 编写的白皮书并进一步扩展了这一点。
我的主要问题确实是,由于多个查询正在运行并同时保持打开以询问数据,我希望在连接和 SQL 查询方面提高服务器端效率,任何人都可以为我指明方向以获取有关如何进行的指导设计一个真实世界的 Datasnap Server 应用程序,因为演示的细节不够详细。
谢谢马特
您必须在设计中做出决定:
(中间服务器)将管理会话或客户端将识别每个连接的会话(有状态与无状态)
(中间服务器)您希望拥有多少缓存数据。您可以仅缓存一些烦人的非常稳定的表,并且仅在它们更改时才查询它们(如果所有修改都通过中间服务器进行,如果不是,则需要在表上使用任意标记(GUID,计数器)之类的东西来匹配数据改变)。
(客户端/中间服务器)如果您的客户端将始终获得完整的数据集合或只是集合的片段。(例如:一个产品可以有一个 categoryId 列,它是一个 Category 表的 FK。您可以一直发送两者,或者客户端可以只请求产品数据)。
(中间服务器/RDBMS)您可能必须提供某种形式的自定义搜索。如果您知道最常用的搜索条件,您可以提供(如果需要)索引覆盖来做到这一点。
(Mid-Server/RDBMS)不要把好的数据集带到中间服务器,除非你打算对数据做一些积极的缓存和/或对它们有一些好的用途。中间服务器只是 RDBMS 的另一个客户端应用程序 - 如果两者都在同一台机器上,您可以进入与 RDBMS 的内存/CPU/IO 竞争。
(中间服务器/RDBMS)在中间服务器上执行你的业务规则,是许多纯粹主义者的口头禅。对我来说,平衡是关键。假设 RDBMS 有 2000 个存储过程(我没有夸大其词,有这么多 SP 的真正业务),并且您的中间服务器可以在 SP 解决的 2000 个问题中的 1500 个方面做出出色的工作,非常棒并且做到了。但是,如果最后 500 个可能是最坏的变化,那就别管他们了。它可能比 1500 更麻烦。所以将两者混合起来,将这 500 变成另一个版本的软件项目。
(中间服务器/RDBMS)我所说的存储过程也可以应用于触发器和其他任何其他类型的 RDBMS 服务器功能,可以让您的生活更轻松。
(Mid-Server/DataSnap)大部分粗略的细节可以让给数据集提供者。但是学习在需要时利用 OnBeforeUpdateRecord 事件进行自定义处理。
(Mid-Server/DataSnap)你知道你可以通过下面这种代码创建一个只包含修改数据的ClientDataset吗?你无法想象它有多么有用...... :-)
Cds_New.Data := Cds_Updated.Delta;