2009-08-21 81 views
4

這是我希望在今天編程的時候看到的東西,但是我從來沒有見過這樣的應用程序。您的意見非常感謝。有沒有辦法在運行另一個模擬器時模擬特定的數據庫引擎?

假設我們有一個需要MSSQL服務器作爲DBMS的應用程序。假設你只需要安裝它並做一些事情。 (即你不打算在生產服務器等)

在這種情況下,它可能是一個開銷,首先安裝MSSQL。我建議像可以使用其他DBMS來存儲數據的軟件橋。換句話說,應用程序「看到」一個MSSQL實例,但在其下面可能是Access。橋樑sholud做了某種轉換。

另一個例子:你有MSSQL但某個應用程序需要Oracle。那麼你必須購買Oracle。但有了橋樑之類的東西,您可以將信息放入MSSQL DBMS中。網橋像Oracle一樣監聽端口1521,因此應用程序「認爲」有一個Oracle安裝。

  1. 這是一個無法實現的想法嗎?

  2. 有沒有這樣的應用程序?

  3. 如果是這樣他們是什麼?

謝謝... :)

添加澄清:應用程序可能來自第三方。你對這個內部架構沒有任何認識。你只知道它使用某個DBMS。我正嘗試使用除第三方軟件需求以外的其他DBMS。

+0

我編輯了標題以更好地反映您尋求的內容。 – 2009-08-21 09:37:03

+0

希望你有我的想法.. :)感謝哥們 – 2009-08-21 09:39:54

回答

4

應用程序通常不依賴於特定的數據庫服務器,或者它們依賴於某個原因。

如果一個應用程序要求的Oracle或SQL Server,或什麼的,這是因爲它依賴於這個特定供應商的實施細則來運行它的SQL,存儲過程等有沒有辦法,你可以模擬與一個訪問數據庫,例如...

如果您的應用程序只需要運行一些非常簡單的SQL(即基本插入/選擇語句),它可能使用標準驅動程序(odbc,ado等),而這些驅動程序可以容納每個主要的sql數據庫引擎。根據我的經驗,「簡單應用程序」不要求特定的數據庫供應商。

+0

這個想法是「如果應用程序很簡單,爲什麼我們需要應用程序需要相同的DBMS。」 – 2009-08-21 09:37:07

+0

你有沒有具體的應用?如果它寫得很好,它可能使用標準的驅動程序來訪問sql數據庫... – Brann 2009-08-21 09:39:58

+0

@ Brann - 有些應用程序可以做到這一點..但不是每個應用程序.. :( – 2009-08-21 09:41:10

3

這是ODBC應該解決的問題:-)。

但在回答你的問題:

它是一個想法,不能執行?

它可以實現。

這將是單調乏味且費力不討好的工作,而且你的聽力會非常有限。在我看來,這不值得去做。

有沒有這樣的應用程序?

沒有我所知道的。

如果是這樣他們是什麼?

沒有我所知道的。

......

在評論部分中Chandrasekar注瞻:

已經在超級用戶的角度來看看......他有一個很好的應用,但他不能沒有一些DBMS就可以使用它。但是他仍然不是程序員做某事。所以他們需要這樣的產品

我同意它有應用程序,但它有一個非常有限的聽衆:)。

你的建議是像firefox插件'ietab',只有你不會有ie安裝...所以,而不是嵌入,即你需要完全重新實現,即使用Firefox的渲染窗口。

只是我的意見:這是太多的努力......只是安裝第二個數據庫更簡單。

+1

看看超級用戶的角度..他有一個很好的應用程序,但是如果沒有一些DBMS,他就不能使用它,但是他仍然不是一個程序員,所以他們需要這樣的產品 – 2009-08-21 09:52:21

+0

「安裝第二個數據庫更簡單」。還有一些其他問題。組織政策,成本因素,處理ETAs ..其他許多事情:) – 2009-08-21 10:44:16

0

如果此應用程序使用ADO連接到SQL Server,並且可以修改連接字符串,那麼使用不同的數據庫非常容易:更改連接字符串!但是,其他數據庫必須能夠支持SQL Server的所有功能。此外,該軟件從未在另一個數據庫上進行過測試,因此應用程序可能會崩潰&刻錄。

如果您不能更改連接字符串,或者應用程序不使用ADO,那麼事情就更加複雜和非常接近不可能。

我曾經在一個項目上工作,需要合理的數據庫獨立性。數據庫必須支持存儲過程,但沒有任何其他限制。默認情況下,我們試圖同時支持SQL Server和Oracle。 (我們也支持Interbase,但從來沒有做過這方面的宣傳。)雖然我們確實設法保持它與數據庫無關,但我們確實需要解決一些小問題。特別是在我們的查詢中加入了一些我們剛剛通過向存儲過程添加更多邏輯而解決的令人討厭的問題。

0

「這是ODBC應該解決的問題:-)」。

這也是SQL想要解決的問題。

在我看來,這個問題存在的原因是,世界似乎不同意足夠什麼樣的數據操縱語言/接口應該看起來像。

我懷疑如果這是可以解決的話,它已經完成了。

0

我聽到的最接近的是EnterpriseDB,他們在Postgres之上構建了一個圖層,因此它看起來更像Oracle。

但請記住,這些數據庫具有專利和版權所涵蓋的功能,所以競爭對手的產品可以如何模仿真實的東西存在限制。

模仿「向下」可能比向上更容易。例如,MS-Access將無法模仿Oracle或SQL Server的大部分功能,而SQL Server模仿Access等更簡單的數據庫的機會更大。

0

應用程序通常依賴於特定的數據庫服務器。每個數據庫實現的東西都略有不同 - 甚至是具有共同祖先的MSSQL和Sybase。

任何橋樑,無論如何它試圖抽象的差異,會留下一些暴露。這些可能會在應用程序中產生微妙的錯誤,這些錯誤可能最初似乎起作用,但隨後會失敗,或者更糟糕的是,損壞的數據。

此外,應用程序供應商不會支持你在這種情況下 - 他們會簡單地說,他們不支持使用情況下,你應該刪除的橋樑和安裝任何數據庫的目的是針對的正確實例。

總之,我不認爲這是值得的應用程序的風險錯誤微妙,並且被拋不支持,即使應用程序是不是特別重要。如果您不喜歡應用程序使用的底層數據庫,請選擇其他應用程序。

相關問題