2011-03-15 22 views
2

我有一個數據庫客戶端應用程序,它運行在連接到網絡上的SQL Server數據庫的LAN上。我現在想將數據庫在線移動到託管的Internet服務器上,但是,通過Web繼續正常的SQL ADO連接充滿了問題。Delphi:基於Internet的數據源

你們用什麼來公開數據通過網絡,最好仍然能夠使用數據庫控件客戶端?

回答

2
+0

謝謝,我聽說過datasnap,但我試圖避免創建一箇中間層。我是hopinh我可以以某種方式通過XML公開SQL Server的數據,並讓我的應用程序的數據集使用XML數據,就好像它是本地sql連接一樣,畢竟XML數據集已有很多年了。這不是一個選項? – 2011-03-15 12:40:14

+0

你的方法有什麼好處?它只會減慢你的應用程序(原生數據 - > XML - >你的應用程序),不得不對數據進行編碼和解碼。你最好解釋一下你直接連接數據庫的問題(不可靠的連接?太慢?其他?)以及需求是什麼。 – 2011-03-15 13:44:15

+0

當然會有性能上的犧牲,但我可以通過始終打開的端口80進行連接,並且我使用的是一種互聯網接入技術。這是遠程數據連接。如果XML有太多的開銷,還有其他長期的標準。奇怪的是,自從2003年以來MS SQL一直在發佈XML數據集,而Delphi自此之前已經有了XML組件,但尚未實現。 – 2011-03-16 21:32:04

4

Web Services(SOAP和WSDL)。 Delphi最近的版本能夠創建和使用Web服務。 DataSnap也很有價值,但我認爲它是數據庫架構中的「中間層」,而您的中間層可能會通過肥皂與您的Web和桌面客戶端進行交談,儘管您可以直接訪問datasnap,並且在那裏對任何一方都有好處。直接自定義Soap實現(與使用基於SOAP的DataSnap體系結構相反)是很多人喜歡的,因爲使用它的語言和平臺數量衆多。雖然它能夠「通過網絡」工作,但有些人抱怨說,它不支持SSL,至少不是很好(你必須做很多工作才能添加SSL)。 RemObjects也有競爭的第三方框架,許多人認爲這些框架是有價值的,它們是商業的,雖然不便宜,但是很划算。

更新:直接讓你的SQL數據庫直接連接到互聯網顯然是愚蠢的。但這幾乎就是你要求的。你要麼建立一箇中間層,只通過一個接口公開你想要公開的內容,只准確地向你的數據庫提供你想要的內容,或者你想要允許的內容,或者你回退到100%「直接攻擊我的數據庫,你不友好的互聯網,你「。我甚至懷疑微軟自己會推薦你直接通過互聯網公開SQL連接。所以它是中間層,或者是直接的,你的選擇。如果你想在你的解決方案中使用數據感知控件,你可以這樣做,我會推薦使用SOAP的DATASnap。

+0

謝謝,雖然我之前在delphi上使用過SOAP和WSDL,但我還沒有遇到一個控制集,它允許我在應用程序中使用數據庫感知組件。你提到「Delphi最近的版本」 - 我使用的是2007年。這就是爲什麼我沒有看到它? – 2011-03-15 12:36:37

+0

Web服務**是**中間層 - 您的應用程序和數據庫之間有一個Web服務器和一些翻譯代碼。 – 2011-03-15 13:51:42

+0

聽起來像Hein想要一個沒有中間層的中間層。 – 2011-05-31 16:09:23

1

由於您使用的是SQL Server,因此您應該考慮Azure平臺,因爲它包含雲基礎SQL Server平臺。

自託管的Windows + SQL服務器需要兩者和您自己的管理的許可證。

Azure通過MS客戶端庫支持,Azure Web服務位於新版Delphi版本的標準控制集中。

+0

互聯網上的ADO? – 2011-03-15 12:28:06

+0

謝謝,但對不起,Azure非常昂貴,特別是對於較小的應用程序。客戶很少同意產品的每月費用。他們寧願支付一次性費用。 – 2011-03-15 12:41:39

+0

@Warren P - 我無法在託管服務器上打開SQL端口。 – 2011-03-15 13:19:35

2

如果您需要/希望使用標準的數據庫感知控件,則需要使用能夠將數據映射到TCustomDataset後代客戶端的框架。 Delphi中的這個框架是Datasnap,儘管還有其他的(即RemObjects)。通過SOAP提供的純Web服務可讓您從服務器獲取數據,但整個接口由您決定,SOAP可讓您調用遠程函數,僅此而已,它不支持「面向數據庫的接口」(發送查詢並返回結果集),而Datasnap & C.做。

唯一的問題是Delphi 2007中的Datasnap使用的是早在2009年之前就已被新實現取代的技術。在Delphi 2007中,Datasnap同時支持其DCOM實現的HTTP代理(通過ISAPI dll,但IIRC它可能與最近的IIS版本有問題)以及SOAP實現(使用TSOAPConnection)。他們都注意以特殊格式封裝請求和響應,以允許標準的delphi數據庫訪問數據。從2009年開始,有一個新的實現可以使用不同的傳輸(包括HTTP),但是哪個恕我直言從XE開始就變得有些可用(特別是因爲安全和代理問題)。您將不得不更改所有數據訪問組件,並查看應用程序設計。

因爲無論您使用哪種技術訪問遠程數據庫,當數據通過較慢的連接時,應用程序設計都非常重要。如果應用程序被設計爲從服務器請求太多數據,經常訪問它等等,它可能會帶來可怕的性能。通常更好的方法是需要適當的子集,只在需要時纔在本地進行闡述(甚至更好,要求遠程服務器執行任何可以輕鬆遠程執行的活動,即使用存儲過程或查詢),然後將更改發送到服務器。

+0

感謝Idsandon,我認識到網絡連接的應用程序對於Lan來說比較慢,但我們說每個屏幕每個查詢少於20-30行,我已經通過互聯網直接通過sql連接進行測試,響應非常好。爲了回到您的建議,我應該忘記2007年並升級到XE嗎?即使這樣,你聽起來並不令人信服(有點可用)。 – 2011-03-16 21:29:04

+0

由於安全問題,我不會使用直接連接,至少我會保護與VPN的tje連接。我只通過SOAP使用D2007 datasnap進行實驗,我通過DCOM廣泛使用它。 DCOM不是防火牆友好的(它使用隨機端口),雖然它可以配置爲使用給定的端口範圍不是最簡單的協議來配置在Internet上工作,在LAN域中效果最好,但我發現問題套接字代理(scktsrv。EXE)和AFAIK HTTP代理(httpsrvr.dll)長時間沒有更新,在使用它之前我會測試它是否按預期工作 – 2011-03-16 22:47:00

+0

在XE Datasnap中有所改進,但恕我直言,其數據保護仍然存在缺陷方案,但它的設計目的是通過HTTP(並且不使用DCOM)從頭開始工作如果您的數據不是非常敏感,您可以嘗試一下,我的建議是下載試用版並查看升級是否物有所值。請注意,升級將意味着完全使用Unicode,您也必須在這方面更新您的應用程序,這可能會抵消許多優勢,具體取決於端口的工作量。 – 2011-03-16 22:48:11

2

您可以在服務器和客戶端之間配置VPN,並且您可以使用相同的應用程序通過安全通道連接到基於雲的SQL服務器。

性能可能是一個問題,它取決於應用程序的設計方式。 SQL Server是恕我直言的可以通過VPN運行的可用數據庫,因爲它經過了很好的優化,可以最大限度地減少客戶端和服務器之間的往返次數。

Windows服務器隨附VPN組件,您也有免費/開源選項,如OpenVPN

+0

我猜想整個雲概念與使用VPN的連接兩個站點有點不同。數據庫設計不如應用程序設計重要。此外,您可能需要調整數據庫客戶端以在其使用的每個「數據包」中攜帶更多數據。還需要發送「保持活動」數據包,以避免會話被認爲客戶已經死亡而回滾。 – 2011-03-15 16:54:39

+0

@ldsandon,我知道*整個雲概念*與使用VPN的兩臺機器或網絡的連接不同,但我不明白雲概念如何排除客戶端網絡或計算機與遠程服務器之間的VPN連接。 – jachguate 2011-03-15 17:16:54

+0

@jachguate,VPN的問題是我必須授予我所有用戶訪問我的服務器的權限。鎖定是一個痛苦。幫助他們建立VPN更加痛苦,特別是如果我打算將這個應用分發給數百個用戶。 – 2011-03-16 21:25:44