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