你能够在Linux,BSD等平台上运行PostgreSQL（当然，在Windows上也可以）IT行业的开发人员都清楚跨平台是当今一个关注点。支持跨平台可以说是Java杀手级的特性，其实Java是一门尚显粗糙、丑陋的编程语言，但它依然获得了巨大的成功，广泛的影响及普及。Linux与苹果的崛起使微软在桌面领域无法再保持垄断地位。云服务的灵活性和高性能虚拟化技术的易访问性，使IT基础设施越来越多样化。跨平台软件能够提供给用户控制他们的基础设施。（工作中，我目前管理着好几个PostgreSQL 数据库，一些运行在Windows平台上，一些在Ubuntu Linux上。我和同事自由地在这些平台之间移动代码和数据库数据。我们使用Python和PHP，因为他们在两种操作系统上都能运行。它们全部运行得很好。） 微软的政策一直都是供应商锁定。 他们不开放自己的代码；他们不提供跨平台版本的软件；他们甚至自己创造一个完整的生态系统，.NET设计用于为微软用户和非微软用户搭建了一座桥梁。 这对他们是有利的，因为这种方式保证了他们的利润。 这对你（用户）是不利的，因为微软限制了你的选择，而且为你创建了一些不必要的工作。 这不是一篇对比 Linux和 Windows的文档，尽管我确定我最后会提到几点。 可以肯定地说，对于真正的 IT工作， Linux（和类 UNIX操作系统家族： Solaris， BSD等）把 Windows甩出几条街。 类 UNIX操作系统主宰着服务器市场、云服务、超级计算（在这个领域它近乎垄断）和科学计算，一个原因就是 - 这些系统是技术人员为技术人员设计的。 最终，他们以巨大的力量和灵活性换得了用户友好性。 一个合格的类 UNIX OS 不仅仅是一个漂亮的命令行集合 – 它是一个包含各种程序、实用工具、功能的生态系统，并且提供支持使完成工作变得高效和有趣。 一个合格的 Linux黑客可以用一行被抛弃的 Bash脚本达到目的，但是这个任务在 Windows中是艰巨且耗时的。 （例如，某一天，我在查看朋友影片收集情况，他对我说，他认为他的文件系统中文件的总数量太多，他想知道究竟有多少影片文件，还想知道他是否可还以把一个大型的文件夹结构复制到影片文件夹下。我使用下面语句对每个文件夹及其子文件夹所包含文件数进行了计算：
整件事情做下来编写花了一分钟，运行花了一秒钟。同时还证实某些文件夹有问题，并告诉他具体哪个文件夹有问题。Windows下怎么能做到这些呢？） 在做数据分析时，关系型数据管理系统(RDBMS)不可能处在真空里；它是整套工具中一部分。因此它所处的环境就非常重要。MS SQL服务器只可在Windows系统上使用，而Windows是一个很差劲的可用于分析的环境。 1.4程序语言特性这可是一个大问题。 一个“纯”字可以概括SQL，因为它只专注于它被设计的初衷，那就是关系型数据的操作和查询。如果你尝试用它做更多的分析处理的话，比如复杂的利息计算、时间序列分析以及通用算法设计，你将很快达到它的极限。SQL数据库的提供者对这些比较了解，所以几乎所有的SQL数据库都实现了某种程序语言。这就是使得数据库用户可以写命令式风格的代码以用于更复杂或繁琐的任务。 PostgreSQL的程序语言支持比较好。对它来说在一个小范围内是不可能做到公正的，不过这只是一个样本。这些程序语言的任何一个都可以用来写存储过程和函数或直接转储到一个内联执行的代码块。
MS SQL Server 内置的面向过程编程语言 (T-SQL 对 SQL 扩充的一部分) 既笨拙， 又缓慢， 各种缺点。 就如 Microsoft 自己的文档说的那样， 它有时会容易产生一些奇怪的错误和 Bug。 我还没见过哪个程序员说他喜欢 T-SQL 的。 那放到 MS SQL Server 上面用的 .NET 组件呢 ? 这种不算面向过程语言支持， 因为你不能直接向数据库引擎提交代码。要知道， 可管理性和人类工程学（ergonomics ）都很重要。 直接将 Python 代码嵌入数据库查询语句中， 既简单又方便； 启动 Visual Studio， 然后管理一堆项目，复制一堆 DLL 文件 (都是在图形用户界面中处理的，不能很好的脚本化，版本控制， 自动化， 以及审查 )其实挺尴尬的，而且容易出错，扩展性又不好。总之， 这种机制在很大程度上受限于.NET 语言。 1.5支持原生正则表达式正则表达式（regexen或者regexes）对于分析工作来说就像会算术一样的基础，对于大量的文本处理任务来说它们是首选（经常是唯一选择）。不支持正则表达式的数据分析工具就像一个没有座的自行车一样，你仍然可以用它，但是充满痛苦（菊花都残了当然痛—译者加）。 PostgreSQL有开箱即用的正则表达式支持。看几个例子： 取得所有以重复数字并且紧跟元音字母开头的行：
取得某一个字段中第一个出现的单独的十六进制字符串：
将一个 字符串以空白字符分割，并且以单行的形式返回每一部分：
查找一个字符串中最少有10个字母的单词（不区分大小写）：
MS SQL Server有 LIKE ，SUBSTRING，PATINDEX 等等，不过它们与恰当的正则表达式支持不具可比性（如果你对此怀疑，你可以尝试使用它们来实现上面的例子）。有第三方的库可用于MS SQL Server，它们不像PostgreSQL的支持那样好，并且获取和安装它们会增进管理开销。 还要注意到PostgreSQL的支持扩展程序语言特性也让你有好几个其他的正则表达式引擎可用，当然也包括它们的各种特性。比如Python的正则库提供的对正向和负向后行断言的支持。这正符合PostgreSQL的一贯作风，给你干好工作的所有你需要的工具。 1.6自定义聚合函数这是一个PostgreSQL和MS SQL Server两者都提供的一个技术上的特性。不过，在实现上却有巨大的不同。 在PostgreSQL中，自定义聚合很方便并且使用简单，产生了可以快速解决问题和可维护的代码：
简单吧？自定义的聚集函数主要关注的是内部的状态和我们输入新值给这个聚集函数时修改这个状态的方法。在这个例子里，我们假设一开始每个客户的余额为零，而且累计利息也为零，接着我们每天适当地进行利息累计，并对每天的支付和撤消记账。在每个月的1号，我们进行利息复合。注意：这个聚集函数接纳 顺带说明一下，上面的第二个链接里的例子实现了简单的字符串连接聚集。注意：实现如此简单的功能需要大量的代码和技巧（而PostgreSQL内部提供了此功能，随拿随用。这可能是因为这个功能有用！）MS SQL服务器还禁止在聚集函数里指定排序，使用这样的函数无法完成我现在要完成的任务-在MS SQL服务器里，字符串连接的顺序是随机的，因此使用这个函数查询的结果就是无法确定的（即每次运行结果都可能不同），而且这样的代码也不会通过质量审查的。 缺乏排序支持还可能使得以前编写的代码无法运行，比如上面计算利息的例子。正如我所说，你无法通过使用MS SQL服务器自定义的聚集函数完成当前的任务。 （实际上，可以让MS SQL服务器使用纯SQL语句实现结果可以确定的字符串连接聚集，不过，你需要多次使用 |
