<你最喜歡的數據庫>最大的缺點是什麼？

我們都有我們最喜歡的數據庫。如果你客觀地看待你選擇的數據庫，它有什麼缺點，有什麼可以改進的？<你最喜歡的數據庫>最大的缺點是什麼？

的規則：

一個與每缺點回復;
該限制的簡短描述，其次是;
更詳細的描述，如何做得更好的解釋或另一種沒有相同限制的技術的例子。
不要遺漏任何你沒有廣泛使用的數據庫。在其他技術上很容易引起猜忌，但我們希望從你的經驗中學習，而不是偏見。

來源

2008-09-23 pappes

Oracle數據庫是

甲骨文做的事情做得很好，但許可費用是可怕相當昂貴。 Oracle XE的發佈改善了這一點，但是這樣做的侷限性意味着它對您的解決方案產生了限制。

來源

2008-09-23 08:00:04 pappes

PostgreSQL沒有一個好的故障轉移解決方案，但我知道他們正在處理它。

來源

2008-09-23 08:00:48

SLONY很好的填補了這個空缺。 – user11318 2008-09-23 16:12:06

數據庫的Microsoft SQL Server

缺陷鉅額的許可費用

說明

SQL服務器具有強大的功能，它很好地集成.NET開發。問題是，當您必須從共享數據庫擴展到專用數據庫時，許可成本非常高。實際上，這導致數據庫應該真正運行在專用服務器上，託管在具有性能和安全問題的共享服務器上。

這不會發生在MySQL或PostgreSQL上。不支持存儲過程：

來源

2008-09-23 08:02:48 Sklivvz

數據庫：SQL精簡版

缺點。

無論這個限制如何，這個數據庫都有其'特別用作客戶端緩存的應用程序，可以是智能客戶端或分佈到移動平臺。

來源

2008-09-23 08:07:22 ArielBH

數據庫的Microsoft SQL Server 2005

缺陷妥善執行UI

說明

SQL Server Management Studio中不提供出色的用戶體驗：

標籤兵的行爲是奇怪：你一直在尋找合適的標籤
保持對64位版本的崩潰
失蹤的前版本的一些功能，如存儲過程

補助概述這不與2000年版

來源

2008-09-23 08:07:45 Sklivvz

我從來沒有使用過SQL Server 2005，但肯定它們不能比用於SQL Server 2000的企業管理器造成更糟的UI？那將會令人印象深刻。 – 2008-09-29 12:46:49

:)不幸的是它很傷心，但是真的...... 64位版本每2分鐘崩潰...... 32位版本是...... awkard ......並且他們沒有添加最重要的東西：intellisense。 :( – Sklivvz 2008-09-29 13:09:36

我實際上並不認爲UI是DBMS的一部分，但後來我習慣於使用DB2 for z/OS，其中UI通常是ISPF（80x24綠色屏幕，基於文本的菜單等） – paxdiablo 2008-10-04 02:10:20

數據庫MySQL的

缺陷外鍵發生在一些典型的表僅支持ES

說明

夠說。它有明顯的維護影響。

從MySQL manual

外鍵的定義是受以下條件：

兩個表必須是InnoDB表，他們不能是臨時表。

而且here：

對於比其他的InnoDB存儲引擎，MySQL服務器解析的外鍵語法在CREATE TABLE語句，但不使用或存放它。

這不會發生在任何其他主要數據庫中。

來源

2008-09-23 08:13:10 Sklivvz

你爲什麼不把InnoDB用於一切？95％的時間是正確的選擇，不好的地方是你需要最大的插入速度，在這種情況下，你可能不希望被外來速度放緩關鍵檢查 – 2008-09-29 12:40:27

一個非常簡單的原因：您無法控制的遺留表格 – Sklivvz 2008-09-29 13:08:05

數據庫甲骨文

缺陷有關包

描述補助粒度

只能授予對包裝內的存儲過程的權限的包，而不是。或者，您可以授予單個存儲過程的權限，但是您可以將它們放在包之外。這要求你知道誰將使用哪個存儲過程，並且它很難重構。

SQL Server不會發生這種情況。

來源

2008-09-23 08:16:01 Sklivvz

數據庫的Microsoft SQL Server 2005

缺陷缺乏「插入或更新」

說明

您經常需要插入或更新表中的記錄，取決於記錄是否存在。沒有進行原子操作會導致不必要的事務。

這不使用MySQL或SQLServer的2008

來源

2008-09-23 08:19:19 Sklivvz

數據庫MySQL的
缺陷發生服務器將啓動受損的表
說明

如果MySQL有一個被破壞的表 - 無論是在寫入過程中還是其他故障中死亡 - 它都會很高興地啓動並允許用戶繼續進行，就好像問題不存在一樣。當然，它會在日誌中產生一些錯誤信息，但從我的經驗來看，當你試圖弄清楚爲什麼應用程序行爲異常時，這並沒有幫助。

大多數其他數據庫將在啓動時檢測並修復錯誤，或者只是拒絕以任何形式的損壞開始。你需要

來源

2008-09-23 08:21:21 BigMikeD

數據庫的Microsoft SQL Server 2005

缺陷缺乏的數組類型參數

說明

有用的搜索，有很多次，通過一系列的值與之匹配。在SQL 2005中，您可以通過在SQLServer中使用CLR來實現解決方法。考慮到實用性，開箱即可使用此功能會更有意義。

SQL Server 2008或Oracle不會發生這種情況。

來源

2008-09-23 08:21:33 Sklivvz

數據庫MySQL的 5.0.x版本和上述

缺陷環複製錯誤導致數據不一致的不同節點

說明

在生產中最嚴重的問題，我們所面臨的上現在是在MySQL環中，環本身產生錯誤並停止複製。

自5.x.x開始建立環（或主 - 主複製）是可能的：您可以將數據庫鏈接在「環」中，以便將數據複製到對方。每個數據庫節點都會從所有其他節點獲取所有更改。

我們假設錯誤在於自動增量失敗。這也可以從正常複製中得知，但在新版本中，錯誤日誌中沒有足夠的錯誤消息。我強烈建議不要在MySQL中使用這個功能，只要這裏的問題沒有解決。

來源

2008-09-23 08:56:07 Georgi

數據庫PostgreSQL的

缺陷沒有SQL事件探查器

我們詢問了開發商在最近的一次會議上，我知道這是現在他們正在尋找實現一些。

來源

2008-09-23 09:00:29

數據庫 Postgres的

缺陷沒有分析查詢

說明

分析查詢，甲骨文推出，是SQL 2003標準的一部分。不幸的是Postgres還沒有實現它們。

來源

2008-09-23 16:09:58 user11318

數據庫甲骨文

缺陷沒有處理長期的數據類型以及時間過長

說明

甲骨文只用了很長的數據類型，直到9i的（我相信），在該點它被棄用，贊成LOB。這裏有很多代碼，但是它仍然有很長的一段時間，並且還有所有相關的限制。其中最大的一個就是每個表只能有一個長列，而且它必須在列的末尾。請參閱here以瞭解更詳盡的限制條款清單。

來源

2008-09-23 16:19:52

與其他數據庫自動增量相比，我喜歡Oracle中序列的靈活性，但是無法將seq.nextval設置爲pk列的默認值，這有點令人討厭，而且必須解決微不足道的問題。

來源

2008-09-23 19:28:43

數據庫甲骨文

問題臨時表的定義並非私人

說明許多數據庫（例如Postgres的和Sybase），讓您即時創建臨時表，插入其中，如果需要添加索引，然後從它們進行查詢。 Oracle具有臨時表，但臨時表定義存在於全局名稱空間中。因此，臨時表必須由DBA創建，您需要在它們使用的表定義和代碼之間進行同步，並且如果兩段代碼需要相似（但不完全相同）的表定義，則它們需要使用不同的名稱。這些差異使臨時表對開發人員來說不太方便。

是的，我明白查詢優化器具有全局定義的好處。然而，對我來說，缺乏便利性使Oracle的臨時表對我來說幾乎沒有用，而我在Postgres中非常密集地使用它們。

來源

2008-09-23 20:45:16 user11318

數據庫：PostgreSQL的

**問題：**是C＃該連接器例如是不是真的了最新和崩潰擁有先進的功能。

來源

2008-09-23 20:48:14

數據庫：Oracle

問題：表，過程，列等的名稱不能超過30個字符。這真令人氣憤。

問題：它符合JDBC規範。例如，存儲過程不會以符合JDBC的方式返回結果集，而不是返回專有的OUT參數類型。這意味着您不能使用更高級別的JDBC抽象。

來源

2008-09-28 13:02:32 skaffman