SQL Server VS Oracle [关闭]

Question

我正在学习 SQL Server，但对 Oracle 了解不多。谁能给我一个公平的比较？我已经阅读了有关 SQL Server 2000 与 Oracle 9i 的比较，但它有点过时了。 SQL server 2008 赶上 Oracle 11g/i 了吗？

Answer 1

在使用 SqlServer 多年和使用 Oracle 4 个月后，我只需 0.02 美元。

SqlServer 更容易使用，这使您可以专注于您希望数据库做的事情（解决一些业务问题），而不是一直与服务器搏斗。

因为 Oracle 让您配置了如此多的设置，所以有很多方法可以让它们出错。这导致了关于分区、要使用的索引类型等的无休止的讨论。在这些讨论中，没有人考虑业务问题。

打个比方：我曾经有一台 olympus 相机，镜头很好，设置也很简单。我用它拍了很多漂亮的照片，所以我升级到带有各种旋钮和转盘的数码单反相机。这样我的照片就没有一半好，因为我专注于相机而不是主题。

对我来说，这就是 Sql 和 Oracle 之间的区别。 Sql 更易于使用，因此可以完成更多工作。想法从白板到工作代码的速度要快得多。只有当您推动非常大的数据库时，Oracle 才会占据优势，但我什至不确定。我不认为 Oracle 可以处理 SQL 无法处理的事情。

编辑： 此外，由于context switching to PL/SQL，Oracle 在大数据量的数据库内分析方面非常糟糕。因此，如果您想在数据上运行一些复杂的功能，请不要使用 Oracle。另一方面，MS SQL 在这方面大放异彩，因为它不受此问题的影响，并且还具有 .Net 集成。

Answer 2

我是一名软件开发人员。我主要在数据库之上编写软件（或者至少帮助我的团队这样做）。

这就是我对 Oracle 的看法：每次我想做某事时，我过去的经验对理解如何完成当前任务没有帮助。我花了很多时间寻找对神秘错误消息的某种有用解释，结果却发现一些帖子建议 OP 联系 Oracle 支持。我刚刚发现，如果您在 Oracle 10g 中的空间列上有NOT NULL 约束，他们的数据泵导入工具会给出错误（这相当神秘）。即使在删除约束之后，我仍然遇到导入挂起什么都不做的问题。说到数据泵，它只能在本地工作。在远程机器上工作的导入/导出工具已被弃用。当您的过程中有错误时，它会告诉您编译失败，但无论如何都会在不可用状态下创建过程对象。然后你必须运行一个命令来获取错误。用户和权限系统很差。用户是 Oracle 中的模式，但对于所有大量权限，没有权限允许用户访问模式上的所有对象，并且允许用户终止会话需要授予 ALTER DATABASE 权限（这给用户可能比你想要的更多的权力）。对于空间迷，它无法解析它为 SRID 3857 生成的 WKT（当坐标变得足够大并且无法解析该数字语法时，它会吐出 0.00000e6 形式的数字）。是的，其中很多都是具体的例子，但是遇到这些我不能只做我想做的事情的问题对我来说是一种日常体验，在单个任务中会出现多个问题。

我在 SQL Server 方面的经验有限，但我所做的事情对我来说并没有那么粗糙。我能够更轻松地找出问题所在，而且我不记得看到无法帮助我找出问题所在的错误消息。我与 SQL Server 进行过更广泛合作的同事报告了类似的经历。

也许只有我一个人，但与 Oracle 合作似乎一直是一个痛苦而乏味的过程，要寻找奇怪的错误并试图解决我需要的功能缺失并留给我自己实现的事实（比如自动递增键）。我的底线观点是：也许甲骨文可以表现得更好，但前提是你有时间和金钱让甲骨文工作，然后弄清楚如何调整它，也有钱让你的开发人员学习。 Oracle 很难学习和使用。

Answer 3

作为最终用户（非 IT），我对 Oracle 有一种倾向（和偏见）。我在 Oracle 工作了三年，现在已经进入了 MSSS 的世界。就个人而言，我发现 SQL Server 环境不太直观，而且非常“错误”。我不写代码，但我确实需要查询大型数据集，并发现它 (OSD) 更具可扩展性。

Answer 4

我不知道这是否公平，但这是我与两者合作的经验：

1. Oracle 似乎更“强大”了一些，SQL Server 还没有完全赶上一些漂亮的功能。

2. SQL Server 更易于使用，并且与 Microsoft 产品的集成度更高（如果您正在进行 .NET 开发）。

Answer 5

正如 cletus 所提到的，Oracle 具有与 SQL Server 完全不同的锁定结构：“写入器不会阻塞读取器，读取器不会阻塞写入器”，正如 Tom Kyte (his site is a fantastic free resource) 喜欢说的那样。 SQL Server 2005 内置了类似的东西，但这样做是为了在 tempdb 中实现行版本控制，这听起来并不是特别可扩展。而且默认情况下它是关闭的，所以微软的人似乎并不特别相信它。

Oracle 也有一个非常不同的查询缓存结构，因此使用绑定变量或占位符可以产生巨大的差异：“硬”解析（即数据库检查 SQL 语法，就好像它是第一次已经看到）可以保持在最低限度，这意味着只有“软”解析（填充变量）占用开销。从 10g 开始，还提供了绑定“窥视”功能，这样您就可以使用绑定变量而不受数据倾斜的影响。

此外，还有真正高效和简化的全文搜索功能，以及行级版本控制。

Answer 6

我会说：

• Oracle 具有更好的过程语言。与 PL/SQL 相比，T-SQL 感觉只完成了一半。
• SQL Server 有一个更好的优化器。当我使用 Oracle 时，我必须提示每个查询以确保它不会永远完成，SQL Server 可以正常工作。不过，可能是服务器配置错误，这将我们带到了下一点
• SQL 服务器更容易使用。您需要专门的 DBA 来管理 Oracle，但几乎任何 bozo 都可以让 SQL 服务器保持运行。
• Oracle 拥有更好、更可预测且记录更完善的并发模型。
• Oracle 的文档在很多方面都非常出色。
• SQL 服务器与 .NET 更好地集成（就像魔鬼 Linq2SQL）。
• 如果您使用 Oracle，您还必须购买 TOAD，但随附的 Manegement Studio 可以用于 SQL Server。
• Oracle 具有更酷但几乎不需要的功能，例如可扩展索引。

如果要我选择，我会选择 SQL Server，因为它有更好的优化器。但是，当多个人在 SQL Server 中使用相同的行时，我真的感觉不安全。

Answer 7

我相信 Oracle 拥有一长串 SQL Server 没有的特性。这并不意味着您不能在 MSSS 中完成相同的任务，不，但这些特性确实意味着 Oracle 在相同的事情上可以更快

表簇。

我们可以在同一个块/页上存储来自多个表的数据。以包含表、列、索引和约束的系统表为例。如果您没有表集群，为了提取表、其所有列、索引和约束，您将查询父表的名称索引，然后转到父表，读取该行的页面/块。然后获取 PK，将该值放入列表 FK 上的索引中，获取 rowid，转到具有这些行的块/页面，对其他两个表重复。呃...这是很多工作。

在 Oracle 中，您可以根据 Table_PK 指定这四个表将位于同一个表集群中。所以阅读看起来像。检查集群索引以获取该表的位置，并使用一个或几个块获取所有 4 个表的数据。瞧。

在两个系统中，它都有 4 个表，对于应用程序来说，它看起来完全相同相同，但如果最小化读取时间至关重要Oracle 可以更快地做到这一点。

Answer 8

Oracle 的优势在于调优方面，在 Oracle 中您几乎可以更改所有内容...我不知道您是否在 SQL Server 中获得了这种级别的自定义。

在工具方面，SQL Server 大放异彩，它非常易于使用（有限制但仍然非常简单）。

集成...这取决于，如果您使用的是 .NET，那么 SQL Server（即使您也可以使用 Oracle）如果您使用的是 Java，那么 Oracle（您也可以使用 Java 连接到 SQL Server )。

如果你问我选择哪一个，我会说 NONE！，因为你可以获得与 MySQL 或 PostgreSQL 等免费数据库服务器几乎相同的质量和先进技术（而且因为我使用 Python/Django 和 .NET，所以它们整合得很好）。

你应该选择哪一个？我不知道，两个都试试！，安装和玩它们不会花费你超过一天的时间 :)。两者都有优势，而且都很酷，我们已经达到了选择哪个 DBMS 并不重要（4 个大的 DBMS，MySQL、PgSQL、MSSQL 或 Oracle）。

Answer 9

我是一个 SQLServer 人，对 Oracle 知之甚少，但在我看来，SQLServer 与 Oracle 是一个宗教争论。不妨问问Windows、Mac还是Linux哪个更好。

SQLServer 和 Oracle 都是具有出色开发人员、运营和 IT 支持故事的企业级数据库。两者都能够在正确配置和调整大小时处理您想要扔给它的任何数据集，并且在配置和调整不当时都能够停止尖叫。

至于“易用性”，正如我所说，我是一名 SQLServer 人，我发现 SQLServer 真的很容易使用（管理员）。当然，我可能会觉得 Oracle 很痛苦，因为我以 SQLServer 的方式思考。同样，我相信 Oracle 管理员/开发人员会发现 Oracle 易于使用，因为他们认为 Oracle 和 SQLServer 对他们来说很陌生。

我认为两者之间的一个真正区别是 Oracle 是跨平台的，而 SQLServer 显然不是。但是，我不认为这有什么大不了的，因为我不打算用 Linux 取代 Windows。

Answer 10

我曾与 SQL Server 和 Oracle 合作过各种项目。我的想法：

• SQL Server 与 .NET 配合使用效果更好
• 通常，SQL Server 更易于安装和使用。作为一名开发人员，我很少需要 SQL Server 的 DBA，但似乎总是在 Oracle 中遇到一些我需要 DBA 来做的事情。
• 我更喜欢 PL/SQL (Oracle) 而不是 T-SQL (SQL Server) 来编写存储过程
• Oracle 似乎有更重要的硬件要求
• SQL Server 的默认管理工具比 Oracle 附带的管理工具更易于使用
• 开发商店很少将两者混用

Answer 11

最新版本的 SQL Server 和 Oracle 都已为企业做好准备，并且它们的功能大体相似。

显然它们的工作方式不同，但总的来说，您可以在两者中实现的性能和功能大致相当。

如果您想大量引用文章，请在 google 上搜索： SQL vrs Oracle

话虽如此，我确信许可和支持协议存在差异。

就我个人而言，我们有 Oracle 和 SQL Server，这是我过去工作过的地方，比较两者，我在 Oracle 中看不到任何我在 SQL Server 中无法做到的事情（我的角色之一是SQL Server DBA。）。
我相信 Oracle DBA 也有同感。 我们有 10 个 SQL Server 和数据库，数据库从很小到数百 GB 不等。 Oracle 有多个服务器和数据库，而且它们也很大。

在我看来，这已归结为管理/成本问题，而不是过去的技术/功能问题，此外，某些应用程序更适合一个数据库而不是另一个数据库。

我对 i 和 g 含义的最佳猜测（无需查找）。
会是，i 已准备好上网，g 已启用网格。

以下是有关 SQL Server 2010 的一些信息：Microsoft lays out SQL Server road map

这是微软与甲骨文的比较：More Performance | More Scalable | More Value

以下是 Oracle 与 Microsoft 的比较：Oracle(r) Database 10g Release 2 Outperforms Microsoft SQL Server 2005 in Head-to-Head Comparison

Answer 12

现在最终并没有太大的不同。很少有人能做到其他人不能做到，但开箱即用的配置往往会有所不同。

最明显的区别是 Oracle 使用 SEQUENCE，而 SQL Server 使用自增列。各有利弊。有些人更喜欢其中一个。

根据我在 SQL Server 中执行 Top N 查询的经验，似乎比 Oracle 容易一些。

开箱即用的 Oracle 使用 MVCC（未提交的数据不会阻塞其他事务的读取——数据库保持一致的视图）。我最近才发现的 SQL Server 也有这个，但它不是默认选项，并且被称为完全不同的东西。事务隔离级别什么的。

PL/SQL 和 T-SQL 在某些领域的语法有相当大的不同，但概念基本相同。

就我个人而言，我发现 SQL Server management Studio 还可以，但在某些方面却很糟糕，比如它的数据导入/导出无法使用自动增量主键。这是 SQL Server 2005 多年前的一个已知错误。我不知道他们是否在 2008 年修复了它。使用 PL/SQL Developer（不作为 Oracle 的一部分提供；它是一个单独的商业产品），导入和导出变得轻而易举。

Oracle 对 VARCHAR(2) 列有一个恼人的限制：长度限制为 4k。它们在 SQL Server 中要长得多（64k？）。

我发现 SQL Server 安全模型很奇怪。默认情况下禁用 TCP（仅限 Windows 身份验证），然后您必须设置登录和用户？我从来没有完全明白这一点。它似乎过于复杂，而在 Oracle 中它只是：

CREATE USER blah IDENTIFIED BY password;
GRANT CONNECT TO blah;

完成（尽管授予其他一些特权/角色，如 RESOURCE 很常见）。

我从来没有完全弄清楚管理 tstudio 的备份/恢复。如果有人连接到数据库但有人是我试图运行恢复，则恢复会失败。

在有人对我提出上述要求之前，我完全意识到，其中许多源于我缺乏 SQL Server 经验，但老实说，仍然存在一定程度的一致性（抽象）和概念的可移植性，即预计。