數據庫引擎在SQL級別具有多少兼容性？

Question

假設我想要一個可以在後端輕鬆切換數據庫的應用程序。
我主要是想將SQL Server作爲主要後端，但可以靈活地使用另一個數據庫引擎。 Firebird和PostGreSQL似乎（從我簡短的維基百科遊覽中）是最常用的w/SQL Server（加上它們是免費的）。

對於Firebird，PostGreSQL和MS SQL Server，數據庫設置，訪問，查詢等有多類似？

Answer 1

我在一個項目中工作，在這個項目中絕對需要支持許多數據庫，包括Access，SQL Server和Oracle。

所以我知道它可以做到。大多數情況下，DML（SELECT，UPDATE，INSERT ...）是相同的，當然，我們並沒有遇到大問題使它可以在所有數據庫中工作 - 只是偶爾的煩惱。當時MySQL是個例外，因爲它不夠強大。

我們在DDL中發現了很多差異，但是有了正確的架構（我們有這個架構），解決這個問題並不困難。

唯一引起我們問題的是生成唯一的ID - 自動增量是非標準的。在大約40張桌子的數據庫中，只有少數幾個地方需要唯一的ID（良好的數據庫設計）。最後，我們在代碼中生成唯一的ID，並處理任何衝突（交易中的所有事情）。

它的確讓事情變得更容易，因爲我們避免了使用自動增量來輸入ID字段，更難想象唯一的密鑰 - 但從長遠來看更好。

Answer 2

不幸的是，不同供應商的SQL差別很大。除了最重要的SQL之外，幾乎不可能在一些RDBMS上運行 - 然後你進入最低公分母領域。最好使用抽象層來處理至少與數據庫的連接（包括訪問，發送查詢），或者使用ORM來處理SQL本身或每個提供者的SQL。

如果你想看看它們是如何變化的 - 很好的例子是自動遞增ID和獲得最後插入的記錄的ID。

Answer 3

那麼，CRUD的東西應該是相同的，但如果你構建任何複雜的東西，你可能會想要使用觸發器和存儲過程，這就是兼容性變低的地方。編寫一個與DBMS無關的應用程序通常意味着將大部分業務邏輯移到數據庫之外，因此在這種情況下，擁有一個三層應用程序就是恕我直言。

或者，您可以使用一些類似抽象層的包裝庫，但我還沒有看到能夠在一系列DBMS-es上正確執行作業的包裝庫。當然，這也取決於你使用的編程語言。

Answer 4

正如其他答案所指出的，一旦超越了基本的SELECT/INSERT內容（有時甚至是那裏），DBMS就會大幅變化。

我們還必須在多個DBMS之間保持兼容性。在我看來，最好的方法通常是使用某種兼容層。我們有一個內部數據庫抽象庫，但有幾個工具可用。

特別是，看看流行的ORM（Hibernate，nHibernate等）可能會付出代價。他們通常提供DB獨立性作爲一種副作用。至少Hibernate還有一種特殊的查詢語言，它將自動轉換爲您正在使用的DBMS的SQL。