我们都有我们最喜欢的数据库。如果我们客观地看待所选数据库，它有哪些缺点以及可以改进的地方？

规则：

• 每个缺点一个答复；
• 限制的简短说明，然后是；
• 更详细的说明，如何更好地进行说明或者不具有相同限制的另一种技术的示例。
• 不要丢弃我们没有广泛使用的任何数据库。拍摄其他技术很容易，但是我们希望从经验中学习，而不是偏见。

解决方案

Oracle数据库非常昂贵

Oracle做得很好，但是许可成本太高了。 Oracle XE的发行版对此进行了改进，但是其局限性意味着它成为解决方案的增长限制。

PostgreSQL没有很好的故障转移解决方案，但我知道他们正在为此上努力。

数据库Microsoft SQL Server

缺陷巨大的许可费用

描述

SQL Server具有强大的功能，并且与.NET开发很好地集成在一起。问题是，当我们必须从共享数据库扩展到专用数据库时，许可成本确实很高。实际上，这导致数据库实际上应该在专用服务器上运行，并存在性能和安全问题的共享服务器上托管。

对于MySQL或者PostgreSQL不会发生这种情况。

数据库：Sql Compact Edition

缺点：不支持存储过程。

不受此限制的限制，此DB的用途尤其是用作可以是智能客户端或者分发到移动平台的应用程序的客户端缓存。

数据库Microsoft SQL Server 2005

缺陷实施不良的UI

描述

SQL Server Management Studio不能提供出色的用户体验：

• 制表符的行为很奇怪：我们一直在寻找正确的制表符
• 继续在64位版本上崩溃
• 缺少先前版本的某些功能，例如存储过程授权概述

2000版不会发生这种情况。

数据库MySQL

仅某些表类型支持缺陷外键

描述

说够了。它具有明显的维护意义。

从MySQL手册

Foreign keys definitions are subject to the following conditions:
  
  
  Both tables must be InnoDB tables and they must not be TEMPORARY tables.

和这里：

For storage engines other than InnoDB, MySQL Server parses the FOREIGN KEY syntax in CREATE TABLE statements, but does not use or store it.

其他任何主要数据库都不会发生这种情况。

数据库Oracle

软件包赠款的细粒度

描述

我们只能授予对程序包的权限，而不能授予程序包中的存储过程的权限。或者，我们可以授予单个存储过程权限，但随后将它们放在程序包之外。这要求我们预先知道谁将使用哪个存储过程，并且确实很难重构。

使用SQL Server不会发生这种情况。

数据库Microsoft SQL Server 2005

缺少"插入或者更新"的缺陷

描述

通常，我们需要根据表中是否存在记录来插入或者更新表中的记录。没有原子操作会导致不必要的交易。

使用MySQL或者SQLServer 2008不会发生这种情况。

数据库MySQL
缺陷服务器将以损坏的表启动
描述
如果MySQL的表在写入过程中被杀死或者由于其他原因而被杀死，它将很高兴地启动并允许用户继续进行，就好像问题不存在一样。当然，它会在日志中产生一些错误消息，但是根据我的经验，当我们试图弄清应用程序为何表现异常时，这无济于事。

大多数其他数据库将在启动时检测并修复错误，或者只是拒绝以任何形式的损坏启动。

数据库Microsoft SQL Server 2005

缺乏数组类型参数

描述

在搜索中很有用，很多时候我们需要传递一系列要匹配的值。在SQL 2005中，可以通过在SQLServer中使用CLR来解决。鉴于有用性，开箱即用此功能将更有意义。

使用SQL Server 2008或者Oracle不会发生这种情况。

数据库MySQL 5.0.x及更高版本

缺陷环复制错误导致不同节点上的数据不一致

描述

目前我们在生产中面临的最严重的问题是，在MySQL环中，环本身会产生错误并停止复制。

从5.x.x开始，可以建立一个环(或者Master-Master-Replication)：将数据库链接成一个"环"，以便彼此复制数据。每个数据库节点都从所有其他节点获取所有更改。

我们假设该错误位于自动增量失败之后。从正常复制中也知道这一点，但是在新版本中，错误日志中没有足够的错误消息。只要这里的问题没有解决，我强烈建议不要在MySQL中使用此功能。

数据库PostgreSQL

缺陷无SQL事件探查器

我们在最近的一次会议上向开发人员询问了这一点，我了解他们现在正在寻求实现这一点。

数据库Postgres

缺陷无分析查询

描述

Oracle引入的分析查询是SQL 2003标准的一部分。不幸的是Postgres尚未实现它们。

数据库Oracle

缺陷长时间没有很好地处理长数据类型

描述

Oracle直到9i才拥有长数据类型(我相信)，此时不赞成使用LOB。但是，这里有大量的代码，但是仍然很长，并且存在所有相关的限制。最大的问题是每个表只能有一个长列，并且必须在列的结尾。长期来看，这里有更详尽的限制列表。

与其他数据库自动增量相比，我喜欢Oracle中序列的灵活性，但是无法将seq.nextval设置为pk列的默认值有些烦人，并且必须很简单地解决。

数据库Oracle

问题临时表定义不是私有的

描述许多数据库(例如Postgres和Sybase)允许我们即时创建临时表，将其插入其中，如果需要，可以添加索引，然后从中查询。 Oracle具有临时表，但是临时表定义存在于全局名称空间中。因此，临时表必须由DBA创建，我们需要在它们使用的表定义和代码之间进行同步，并且如果两段代码想要相似(但不相同)的表定义，则它们需要使用不同的名称。这些差异使临时表对开发人员而言不那么方便。

是的，我了解拥有全局定义对于查询优化器的好处。但是，对我而言，缺乏便利性使Oracle的临时表对我几乎毫无用处，而我在Postgres中非常频繁地使用它们。

数据库：PostgreSQL

**问题：**例如C的连接器不是真正最新的，并且由于高级功能而崩溃。

数据库：Oracle

问题：表，过程，列等的名称不能超过30个字符。真是气死我了

问题：这是slapdash JDBC的合规性。例如，存储过程不以兼容JDBC的方式返回结果集，而是返回专有的OUT参数类型。这意味着我们不能使用更高级别的JDBC抽象。

数据库：全部

缺点那些认为在设计基准数据库时知道自己在做什么并不重要的人的设计不佳。设计不当对所有数据库造成的问题要比缺少任何功能所造成的问题多得多。因此，我想他们都错过了"读我的脑子，找出最好的解决方案，而无需我思考"的功能。

任何SQL DBMS

缺陷：重复的行

关系模型的优点之一是，它表示没有重复元组的所有内容，即使用具有键且没有重复的关系。不幸的是，SQL不是以这种方式构建的。这使数据库开发人员的生活不必要地困难。 SQL开发人员必须处理没有键的表，并调试返回重复行的查询。