【发布时间】：2010-09-12 07:01:54
【问题描述】：
我们都有自己喜欢的数据库。如果您客观地看待您选择的数据库，它有哪些缺点以及可以改进的地方？
规则：
- 每个缺点回复一个；
- 限制的简短描述，后跟；
更详细的描述，说明如何做得更好或没有相同限制的另一种技术示例。
不要diss任何你没有广泛使用的数据库。对其他技术进行攻击很容易，但我们希望从您的经验中学习，而不是您的偏见。
【问题讨论】：
标签： database rdbms platform-agnostic
【发布时间】：2010-09-12 07:01:54
【问题描述】：
Oracle 数据库相当昂贵
甲骨文做得很好，但许可成本非常可怕。 Oracle XE 的发布已经改善了这一点，但它的局限性意味着它是您解决方案的增长限制。
【讨论】：
数据库 Microsoft SQL Server 2005
缺陷缺少“插入或更新”
说明
通常您需要在表中插入或更新记录，具体取决于记录是否存在。没有原子操作会导致不必要的事务。
MySQL 或 SQLServer 2008 不会发生这种情况。
【讨论】：
数据库 PostgreSQL
缺陷没有 SQL Profiler
我们在最近的一次会议上向开发人员询问了这个问题，我知道他们现在正在寻求实施。
【讨论】：
与其他数据库自动增量相比，我喜欢 Oracle 中序列的灵活性，但是无法将 seq.nextval 设置为 pk 列的默认值有点烦人，而且必须很容易修复。
【讨论】：
数据库 Microsoft SQL Server
缺陷巨大的许可成本
说明
SQL Server 具有强大的功能，它与 .NET 开发集成得非常好。问题是，当您必须从共享数据库扩展到专用数据库时，许可成本非常高。实际上，这会导致数据库实际上应该在专用服务器上运行，而这些数据库托管在存在性能和安全问题的共享服务器上。
MySQL 或 PostgreSQL 不会发生这种情况。
【讨论】：
数据库 Microsoft SQL Server 2005
缺陷用户界面实施不当
说明
SQL Server 管理工作室不提供出色的用户体验：
- 标签行为很奇怪：您总是在寻找正确的标签
- 在 64 位版本上不断崩溃
- 缺少以前版本的一些功能，例如存储过程授权概述
2000 版不会发生这种情况。
【讨论】：
-
我从来没有使用过 SQL Server 2005，但他们肯定不会比 SQL Server 2000 的企业管理器更糟糕的用户界面吗？那将是令人印象深刻的。
-
:) 不幸的是，这很可悲，但确实如此……64 位版本每 2 分钟崩溃一次……32 位版本……很尴尬……而且他们没有添加最重要的东西：智能感知. :(
-
我实际上不会将 UI 视为 DBMS 的一部分。但是，我习惯于使用 DB2 for z/OS，其中 UI 通常是 ISPF（80x24 绿屏、基于文本的菜单等）。
数据库 MySQL
缺陷服务器将启动损坏的表
说明
如果 MySQL 有一个损坏的表——在写入过程中被杀死或其他故障——它会很高兴地启动并允许用户继续进行，就好像问题不存在一样。当然，它会在日志中产生一些错误消息，但根据我的经验，当您试图找出应用程序行为异常的原因时，这无济于事。
大多数其他数据库会在启动时检测并修复错误，或者干脆拒绝启动任何类型的损坏。
【讨论】：
数据库 MySQL 5.0.x 及更高版本
缺陷环复制错误导致不同节点数据不一致
说明
目前我们在生产中面临的最严重的问题是，在 MySQL 环中，环本身会产生错误并停止复制。
从 5.x.x 开始可以构建环（或 Master-Master-replication）：您将数据库链接在一个“环”中，以便将复制数据相互连接。每个数据库节点都从所有其他节点获取所有更改。
我们假设错误在于自动增量失败。这也可以从正常复制中得知，但在新版本中，错误日志中没有足够的错误消息。只要这里的问题没有解决，我强烈建议不要在 MySQL 中使用此功能。
【讨论】：
数据库甲骨文
缺陷太长时间没有很好地处理长数据类型
说明
Oracle 在 9i 之前只有 long 数据类型（我相信），那时它已被弃用，取而代之的是 LOB。然而，那里有大量的代码，它们仍然有很长的时间和所有相关的限制。其中最大的问题是每个表只能有一个长列，并且必须位于列的末尾。请参阅here 以获得更详尽的限制列表。
【讨论】：
数据库甲骨文
问题临时表定义不是私有的
描述 许多数据库（例如 Postgres 和 Sybase）允许您动态创建临时表、插入其中、添加索引（如果需要），然后从中查询。 Oracle 有临时表，但临时表定义存在于全局名称空间中。因此临时表必须由 DBA 创建，您需要在他们使用的表定义和您的代码之间进行同步，如果两段代码需要相似（但不相同）的表定义，则它们需要使用不同的名称。这些差异使临时表对开发人员来说不太方便。
是的，我了解查询优化器拥有全局定义的好处。然而对我来说，由于缺乏便利性，Oracle 的临时表对我来说几乎毫无用处，而我在 Postgres 中非常频繁地使用它们。
【讨论】：
-
不要忘记子查询分解子句——我正在努力消除在我目前的工作中使用临时标签和存储过程进行报告，因为 SQFC 通常会用更少的资源完成这项工作麻烦。
-
为什么要降价？这是对原始问题的一个很好的答案。如果它不是真的，那么这将是一个很好的理由来标记它，但我希望能有评论解释原因。
-
这更多是关于您与 DBA 的关系而不是 Oracle？如果授予权限，您的代码可以通过执行一些直接的 DDL 来创建表。 （我认为你需要调用 EXECUTE_DDL）
数据库：甲骨文
问题：表、过程、列等的名称不能超过 30 个字符。这真令人气愤。
问题：这是草率的 JDBC 合规性。例如，存储过程不以符合 JDBC 的方式返回结果集，而是以专有的 OUT 参数类型返回。这意味着您不能使用更高级别的 JDBC 抽象。
【讨论】：
-
我可以理解在某些情况下 30 个字符的过程名称是个问题，但是如果您的表或列名称那么长，您的 SQL 将很难阅读，我会想到。
数据库 MySQL
缺陷仅在某些表类型上支持外键
说明
说得够多了。它具有明显的维护意义。
外键定义需满足以下条件：
- 两个表都必须是 InnoDB 表，并且不能是 TEMPORARY 表。
还有here：
对于 InnoDB 以外的存储引擎，MySQL Server 解析 CREATE TABLE 语句中的 FOREIGN KEY 语法，但不使用或存储它。
这不会发生在任何其他主要数据库中。
【讨论】：
-
你为什么不使用 InnoDB 做所有事情？这是 95% 的正确选择。不好的地方是您需要最大的插入速度，在这种情况下，您可能不希望被外键检查拖慢。
-
一个非常简单的原因：您无法控制的旧表
PostgreSQL 没有很好的故障转移解决方案，但我知道他们正在努力解决这个问题。
【讨论】：
-
SLONY 很好地填补了这个漏洞。
数据库：Sql 精简版
缺点：不支持存储过程。
不管这个限制，这个数据库有它的用途，特别是作为客户端缓存，可以是智能客户端或分发到移动平台的应用程序。
【讨论】：
数据库甲骨文
缺陷包的授权粒度
说明
您只能授予对包的权限，而不能授予对包内的存储过程的权限。或者，您可以授予对单个存储过程的权限，然后将它们放在包之外。这需要您预先知道谁将使用哪个存储过程，并且很难重构。
SQL Server 不会发生这种情况。
【讨论】：
-
我不同意。与 SQL Server 中的大量 sp 相比，Oracle 的包是一个更好的实现。 IIRC，您还可以定义一个包以使用“执行者”权限而不是“定义者”权限来限制此“问题”。
-
我对包没有任何意见。请重读我的回答。谢谢，
数据库 Microsoft SQL Server 2005
缺陷缺少数组类型参数
说明
在搜索中很有用，很多时候您需要传递一系列要匹配的值。在 SQL 2005 中，您可以通过在 SQLServer 中使用 CLR 来解决问题。考虑到实用性，开箱即用此功能会更有意义。
SQL Server 2008 或 Oracle 不会发生这种情况。
【讨论】：
数据库 Postgres
缺陷无分析查询
说明
由 Oracle 引入的分析查询是 SQL 2003 标准的一部分。不幸的是，Postgres 还没有实现它们。
【讨论】：
数据库：PostgreSQL
**问题：** 例如，用于 C# 的连接器不是最新的并且会因高级功能而崩溃。
【讨论】：
数据库：全部
缺点 - 设计不佳的人认为在设计数据库时知道自己在做什么并不重要。糟糕的设计在所有数据库中造成的问题比任何缺失的功能造成的问题要多得多。所以我想他们都缺少“阅读我的想法并找出最佳解决方案而无需我思考”的功能。
【讨论】：
任何 SQL DBMS
缺陷：重复行
关系模型的优点之一是它表示没有重复元组的所有内容，即使用具有键且没有重复的关系。不幸的是，SQL 不是这样构建的。这使数据库开发人员的生活变得不必要地困难。 SQL 开发人员必须处理没有键的表并调试返回重复行的查询。
【讨论】：