LUPA开源社区 › 首页 ›业界资讯› 技术文摘 › 查看内容

PostgreSQL vs. MS SQL Server

2014-12-3 11:24| 发布者: joejoe0332| 查看: 6958| 评论: 0|原作者: 开源中国七里香, 几点人, BreakinBad, daxiang, MagicBLS, 无若, 台阶|来自: oschina

摘要: 这些年里，我已经太多太多次的讨论了 PostgreSQL 和 MS SQL 的问题。IT 行业中一个知名的原则说：如果你准备不只一次的做同一件事，那就让它自动化。本文是我的自动化方法的谈话。 ... ...

　　从一个数据分析师的视角来对比两个关系型数据库。

0.本文是关于什么的？

　　我在一个全球专业服务公司做数据分析师（你肯定听说过的）。我干了大概有10年。10中我处理数据、数据库软件、数据库硬件、数据库用户、数据库程序员以及数据分析方法，所以我对这些东西了解的比较多。我经常遇到对相关内容了解很少的人，虽然他们中的一部分并没有意识到这件事。

　　这些年里，我已经太多太多次的讨论了 PostgreSQL 和 MS SQL 的问题。IT 行业中一个知名的原则说：如果你准备不只一次的做同一件事，那就让它自动化。本文是我的自动化方法的谈话。

　　除非另有说明，我指的是PostgreSQL 9.3和MS SQL Server 2014，即使我的经验是在MS SQL Server 2008 R2和2012版。为了公平起见，我将比较最新版的MS SQL Server和PostgreSQL。由于微软的糟糕的文档，我不得不大量的依赖于Google、Stack Overflow以及网络上的用户。因为我对两个数据库的经验不相等，所以我知道像这样的比较不够科学严谨。不过这不是一个学者的练习题，这是现实中的比较。我尽可能让我对于MS SQL Server的了解正确，因为我们都知道要糊弄整个互联网是不可能的。如果我发现我弄错了什么事情，我会修正的。

　　我将以一个数据分析师的角度来比较两个数据库。MS SQL Server可能会因为QLTP后台而踢PostgreSQL的屁股（虽然我比较怀疑），不过那些不是我这里要关注的，因为我不是一个OLTP开发者/DBA/系统管理员。

　　最后，右上角有一个email地址。如果你愿意的话你会用到的，我会尽可能回复的。

　　免责声明：本文所有观点仅代表我个人。

1. 为什么说 PostgreSQL 比 MS SQL Server 强的多

　　额，剧透了。本节从数据分析的角度对比这两种数据库。

1.1. 支持 CSV

　　CSV 其实是转移结构化数据(如: 表)的一种标准方式。不论是哪一种数据库，都能用自己专有的格式，把数据导出来。以这种格式存储的数据，其他软件无法读取. 用来做备份或者复制数据还行。如果想从 X 系统, 把数据移植到 Y 系统，那问题就大了。

　　一个数据分析平台, 既要能读取不同系统的数据, 也要能生成其他系统能读取的分析结果. 也就是说, 要能快速, 稳定, 可重复的, 而且毫无痛苦的读写 CSV. 我再说一次：一个不能很好的处理 CSV 的数据分析平台，就是没用的累赘。

　　PostgresSQL对CSV的支持在业内是顶尖的。 COPY TO和 COPY FROM命令支持RFC4180（最接近官方标准的文档）中列出的所有规格，也支持很多常见的和不常见的变种和方言。这些命令运行速度很快而且很强大。发生一个错误时，它们会给出有帮助性的错误信息。更重要的是，它们不会默默地损坏、误解、修改数据。

　　而MS SQL Server既不支持导入也不支持导出CSV文件。很多人不相信当我告诉他们这一点时。然后，某一次，他们自己验证了这一点。通常他们的观察是这样的：

MS SQL Server默默地清除（truncate）了一个文本字段的数据
MS SQL Server对文本进行编码时发生错误
MS SQL Server抛出一个错误信息因为它不理解引用或转义（出乎人们的意料，对CSV来说引用和转义不是特殊的扩展。从字面上看，引用和转义是每一个人类可读的数据序列化规范的基本概念。不要相信那些不懂这些东西的人。）
MS SQL Server导出损坏的、不可用的CSV文件
微软有一篇惊人的文档。他们怎么能把CSV这么简单的东西如此复杂化的呢？

　　如果你不相信，下载这个格式正确的、符合标准的UTF-8编码的CSV文件，用MS SQL Server计算文件中最后一列（共有50列）字符串的平均长度（或者是字符的数量，等等）。继续，试一下。

（你得到的答案将是 183.895。）

　　当然，事实上，对 PostgreSQL 来说，确定这么做非常简单。最耗费时间的地方是创建保存这些数据的且具有50个字段的数据表。微软本身似乎就很难理解CSV文件；而且打开这样的文件还会引起Access和Excel中断。

　　痛苦但却是事实的情况是：我了解到近期一些数据库编程人员花费大量的时间和精力编写Python代码，以实现对CSV文件的“清理”，从而让MS SQL服务器可以把这些文件的内容导入到数据库里。但是，这种处理方法不可避免的要更改实际的数据。这就像花费大量金钱购买了Photoshop，然后不得不编写一些定制的代码来让Photoshop打开JPEG，到头来仅仅发现只是稍稍修改了图片那样让人抓狂。

1.2.人机工程

　　值得一提的是每个数据分析平台都是图灵完备的，这大概意味着任何一个数据分析平台可以做其他数据分析平台做的任何事情。也就不存在“你可以在A软件中做X 这件事而不可以在B软件中做X这件事”。即你可以在任何软件里做任何事情-所不同是难易程度。好的工具让你要做的事情做起来非常简单；差的工具就会让你要做的事情做起来很难。说到底就是这么回事。

　　（理论上来讲这一切都是正确的，然而现实中却不是这样的-例如，我了解到没有关系型数据库管理系统(RDBMS)使用3D图形。不过，任意一个关系型数据库管理系统都可以模拟GPU执行任何图形计算。）

PostgreSQL支持DROP SCHEMA CASCADE，它会删除模式以及该模式下的所有数据库对象。对一个强壮的分析方法来说，做到这一点非常、非常重要，因为此时分割和重建是进行可重复的、可审计的协作分析工作的基本操作方法。而MS SQL服务器却不是这样的。你不得不手工删除该模式下的所有对象，而且要按照正确的顺序删除，因为在你试图删除一个其他对象依赖的对象时，MS SQL服务器只会抛出一个错误。这使得整个处理过程非常笨拙。

PostgreSQL 支持 CREATE TABLE AS。一个简单的例子如下：
?
1
2
3
4
5
6
7
CREATE TABLE good_films AS
SELECT
  *
FROM
  all_films
WHERE
  imdb_rating >= 8;
这就意味着你可以使用除第一行以外的其他行，并执行，在开发SQL代码时，这是一个常见的且非常有用的处理方式。在MS SQL服务器里，你要采用如下代码才能以上面的方式创建表：

?
1
2
3
4
5
6
7
8
SELECT
  *
INTO
  good_films
FROM
  all_films
WHERE
  imdb_rating >= 8;
此时，要执行普通的SELECT语句的话，你需要注释或者删除INTO部分。是的，注释两行非常简单；不过这不是我们关注的地方。我们关注的是在PostgreSQL里，你不需要修改代码就可以执行这个简单的任务，而在MS SQL服务器上，你无法做到这一点，而且你要做到这一点还会带来另一个潜藏的漏洞和令人讨厌的东西。

在PostgreSQL里，你可以在一次批处理里执行你愿意执行数量级的SQL语句；只要每个语句都以分号结束，你就可以执行你所想到的任何语句组合。对于哪些要执行自动批处理、构建重复数据或者进行输出的程序来说，这是一个非常重要的功能。在MS SQL服务器里，在一个批处理的SQL语句中间不能出现CREATE PROCEDURE语句。这么做没有任何好的理由，仅仅是随意加的一个限制。此时就意味着需要额外的手工操作来执行大量的SQL批处理。手工操作会增加风险，降低效能。
PostgreSQL 支持 RETURNING 子句，允许 UPDATE,INSERT 和 DELETE 语句返回已更改行上的数据值。这么做非常简洁有益。MS SQL 服务器有个 OUTPUT 子句可满足这方面需求，不过它需要单独定义表变量来实现此功能。这么做很笨拙而且不方便，还迫使程序开发人员创建并维护不怎么需要的代码。

PostgreSQL 支持用 $$ 将字符串括起来, 像这样:
?
1
SELECT $$Hello, World$$ AS greeting;
这样写，对动态生成 SQL 语句很有用，因为 (a) 当嵌入字符串时, 能避免既繁琐, 又容易出错的手工引用和对特殊字符的转义. (b) 由于文本编辑器和 IDE 一般不把 $$ 当作字符串分隔符, 动态生成的 SQL 语句依然根据语法高亮显示。
PostgreSQL 允许你向数据库引擎提交面向过程的编程语言代码; 你可以使用, 像 Python , Perl , R 或 JavaScript, 或其他已被支持的语言(具体看下面), 在同一个脚本文件的 SQL 语句旁边, 加上面向过程的代码. 这样做简洁方便, 易于维护. 同时也方便查看代码, 重复使用, 等等各种好处.
而 MS SQL Server, 你可以使用笨拙, 缓慢, 还有点尴尬的 T-SQL, 或者用 .NET 生成组件(Assembly) 然后加载到数据库中. 。也就是说，你的代码存在两个不同的地方。你得在各种图形界面之间切来换去的修改这些代码。想要将这些东西统一打包放在一起，困难重重。而且也容易出错。

　　诸如此类例子还有很多. 这些问题, 分来开看, 好像没什么. 可是放到一起, 问题就大了. 想要在 MS SQL Server 上面做好一件事, 要比在 PostgreSQL 做的难度大的多. 数据分析师把许多宝贵的时间和精力都花在, 解决各种问题, 手工处理的过程中, 而不是解决真正需要解决的问题.

　　更正: 有人跟我说, MS SQL Server 有个优势, 是 PostgreSQL 不具备的. 那就是在 SQL 脚本中声明变量. 如:

1

2

3

DECLARE @thing INT = 1;
 
SELECT @thing + 6;   --returns 7

　　PostgreSQL 确实不能声明变量. 真心希望它能加上这个实用的功能.

12 3 4 5 / 5 页下一页在本页阅读全文

酷毙

雷人

鲜花

鸡蛋

漂亮

刚表态过的朋友 (1 人)

wised

收藏分享邀请

上一篇：SSL/TLS 部署最佳实践下一篇：每个应用程序都有一个恐怖地下室

快毕业了，没工作经验，
找份工作好难啊？
赶紧去人才芯片公司磨练吧!!

帐号		自动登录	找回密码
密码			注册