我正在研究將基於Delphi的胖客戶端SQL應用程序移植到多層瘦客戶端，並且一直在Delphi 2010中使用Datasnap。我已經完成了Bob Swart編寫的白皮書並擴展這更進一步。Delphi 2010 Datasnap - 設計查詢
我的主要問題的確是我想讓服務器端在連接和SQL查詢方面高效，因爲多個查詢正在運行並保持同時打開詢問數據，任何人都可以指向我的方向有關如何設計真實世界Datasnap Server應用程序的指導，因爲該演示沒有詳細描述。
感謝 馬特
您的設計決定：
（中間服務器）將管理會話或客戶端將確定自己的會話中的每個連接（狀態VS無國籍）
（Mid-Server）您希望擁有多少緩存數據。你可以緩存一些惱人的非常穩定的表，只在它們改變時查詢它們（如果所有修改都是通過中間服務器進行的，如果不是，則需要類似任意標記的東西 - 一個GUID，一個計數器 - 如果數據匹配改變）。
（客戶端/中間服務器）如果您的客戶端將始終獲取完整的數據集合或只是集合的片段。 （例如：一個產品可以有一個categoryId列，這是一個FK到一個Category表格，您可以一直髮送或者客戶端只能請求產品數據）。
（Mid-Server/RDBMS）您可能需要提供某種形式的自定義搜索。如果您對最常用的搜索條件有所瞭解，則可以提供（如果需要）索引覆蓋來做到這一點。 （Mid-Server/RDBMS）除非你計劃對數據進行一些積極的緩存和/或對它們有一些很好的使用，否則不要將很好的數據集帶到中間服務器。中間服務器僅僅是RDBMS的另一個客戶端應用程序 - 如果兩者都在同一臺機器上，則可以在與RDBMS的內存/ CPU/IO競爭中進入。
（Mid-Server/RDBMS）在中間服務器上執行您的業務規則，是許多純粹主義者的口頭禪。對我而言，平衡是關鍵。假設關係數據庫有2000個存儲過程（我沒有過時，有很多SP有真正的業務），並且您的中間服務器可以針對由SP，GREAT解決的2000個問題中的1500個做出傑出的工作並做到這一點。但如果過去的500人可以變成最糟糕的，讓他們獨自一人。它可能比1500更大的麻煩..所以混合這兩個，並使這500個軟件項目到另一個版本。
（Mid-Server/RDBMS）我對存儲過程所說的內容也可以應用於觸發器和其他任何類型的RDBMS服務器功能，這些功能可以讓您的生活更輕鬆。
（Mid-Server/DataSnap）大多數粗略的細節可以讓數據集提供者。但學會利用OnBeforeUpdateRecord事件在需要時進行自定義處理。
（Mid-Server/DataSnap）你知道你可以創建一個ClientDataset只有修改後的數據 這種類型的代碼如下？你無法想象它有多有用...... :-)
Cds_New.Data：= Cds_Updated。三角洲;