我们都有自己喜欢的数据库。如果您客观地看待您选择的数据库,它有哪些缺点以及可以改进的地方?
规则:
- 每个缺点回复一个;
- 限制的简短描述,然后是;
更详细的描述,对如何做得更好的解释或不具有相同限制的另一种技术的示例。
不要diss任何您没有广泛使用的数据库。对其他技术进行攻击很容易,但我们希望从您的经验中学习,而不是您的偏见。
我们都有自己喜欢的数据库。如果您客观地看待您选择的数据库,它有哪些缺点以及可以改进的地方?
规则:
更详细的描述,对如何做得更好的解释或不具有相同限制的另一种技术的示例。
不要diss任何您没有广泛使用的数据库。对其他技术进行攻击很容易,但我们希望从您的经验中学习,而不是您的偏见。
Oracle 数据库相当昂贵
甲骨文做得很好,但许可成本非常可怕。Oracle XE 的发布已经改善了这一点,但它的局限性意味着它是您解决方案的增长限制。
数据库PostgreSQL
缺陷无 SQL Profiler
我们在最近的一次会议上向开发人员询问了这个问题,我知道他们现在正在寻求实施。
数据库Microsoft SQL Server 2005
缺少“插入或更新”的缺陷
描述
通常您需要在表中插入或更新记录,具体取决于记录是否存在。没有原子操作会导致不必要的事务。
MySQL 或 SQLServer 2008 不会发生这种情况。
与其他数据库自动增量相比,我喜欢 Oracle 中序列的灵活性,但是无法将 seq.nextval 设置为 pk 列的默认值有点烦人,而且必须很容易修复。
数据库:甲骨文
问题:表、过程、列等的名称不能超过 30 个字符。这真让人生气。
问题:这是草率的 JDBC 合规性。例如,存储过程不以符合 JDBC 的方式返回结果集,而是以专有的 OUT 参数类型返回。这意味着您不能使用更高级别的 JDBC 抽象。
Database Oracle
Defect Did not handle long datatype well for too long
Description
Oracle only had the long datatype until 9i (I believe) at which point it was deprecated in favor of the LOBs. There is a ton of code out there, however, which still has longs and all of the related restrictions. The biggest of which was that each table could only have one long column and it had to be at the end of the columns. See here for a more exhaustive list of restricitons on the long.
数据库MySQL 5.0.x 及以上
缺陷环复制错误导致不同节点上的数据不一致
描述
目前我们在生产中面临的最严重的问题是,在 MySQL 环中,环本身会产生错误并停止复制。
从 5.xx 开始可以构建环(或 Master-Master-replication):您将数据库链接在一个“环”中,以便相互复制数据。每个数据库节点都从所有其他节点获取所有更改。
我们假设错误在于自动增量失败。这也可以从正常复制中得知,但在新版本中,错误日志中没有足够的错误消息。只要这里的问题没有解决,我强烈建议不要在 MySQL 中使用这个特性。
数据库Microsoft SQL Server 2005
缺陷糟糕的 UI 实现
描述
SQL Server 管理工作室不提供出色的用户体验:
2000 版不会发生这种情况。
数据库MySQL
缺陷服务器将使用损坏的表启动
描述
如果 MySQL 有一个损坏的表 - 在写入期间被杀死或其他一些故障 - 它会非常高兴地启动并允许用户继续进行,就好像问题不存在一样. 当然,它会在日志中产生一些错误消息,但根据我的经验,当您试图找出应用程序行为异常的原因时,这无济于事。
大多数其他数据库将在启动时检测并修复错误,或者只是拒绝以任何形式的损坏启动。
数据库Microsoft SQL Server
缺陷巨大的许可成本
描述
SQL Server 具有强大的功能,它与 .NET 开发集成得非常好。问题是,当您必须从共享数据库扩展到专用数据库时,许可成本非常高。实际上,这导致数据库应该真正运行在专用服务器上,托管在具有性能和安全问题的共享服务器上。
MySQL 或 PostgreSQL 不会发生这种情况。
数据库甲骨文
问题临时表定义不是私有的
描述许多数据库(例如 Postgres 和 Sybase)允许您动态创建临时表、插入其中、添加索引(如果需要),然后从它们中查询。Oracle 有临时表,但临时表定义存在于全局名称空间中。因此临时表必须由 DBA 创建,您需要在他们使用的表定义和您的代码之间进行同步,如果两段代码需要相似(但不相同)的表定义,则它们需要使用不同的名称。这些差异使临时表对开发人员来说不太方便。
是的,我了解查询优化器拥有全局定义的好处。然而对我来说,缺乏便利性使得 Oracle 的临时表对我来说几乎毫无用处,而我在 Postgres 中非常密集地使用它们。
数据库Postgres
缺陷无分析查询
描述
Oracle 引入的分析查询是 SQL 2003 标准的一部分。不幸的是,Postgres 还没有实现它们。
数据库:Sql 精简版
缺点:不支持存储过程。
不管这个限制如何,这个数据库有它的用途,特别是作为可以是智能客户端或分发到移动平台的应用程序的客户端缓存。
数据库甲骨文
包上授予的缺陷粒度
描述
您只能授予对包的权限,而不能授予对包内的存储过程的权限。或者,您可以授予对单个存储过程的权限,然后将它们放在包之外。这需要您预先知道谁将使用哪个存储过程,并且很难重构。
SQL Server 不会发生这种情况。
数据库Microsoft SQL Server 2005
缺陷缺少数组类型参数
描述
在搜索中很有用,很多时候您需要传递一系列要匹配的值。在 SQL 2005 中,您可以通过在 SQLServer 中使用 CLR 来解决问题。鉴于有用性,开箱即用此功能会更有意义。
SQL Server 2008 或 Oracle 不会发生这种情况。
PostgreSQL 没有一个好的故障转移解决方案,但我知道他们正在努力解决这个问题。
数据库:PostgreSQL
**问题:** 例如,用于 C# 的连接器并不是最新的,并且会因高级功能而崩溃。
数据库:全部
缺点 - 那些认为在设计数据库时知道自己在做什么并不重要的人的糟糕设计。糟糕的设计在所有数据库中造成的问题比任何缺失的功能都多得多。所以我想他们都缺少“阅读我的想法并找出最佳解决方案而无需我思考”的功能。
任何 SQL DBMS
缺陷:重复的行
关系模型的优点之一是它表示没有重复元组的所有内容,即使用具有键且没有重复的关系。不幸的是,SQL 不是这样构建的。这使数据库开发人员的生活变得不必要地困难。SQL 开发人员必须处理没有键的表并调试返回重复行的查询。