前端之家收集整理的这篇文章主要介绍了
PostgreSQL 发展史，
前端之家小编觉得挺不错的，现在分享给大家，也给大家做个参考。
前言: 这篇刊载在七月份 Daemon News 专栏的文章，详细述说了著名的数据库系统 Postgresql 的发展过程。众所皆知，数据库是一个庞大而复杂的软件 系统，Postgresql克服重重困难，以『Open Source (开放式源代码)』模式发展成功的故事，有许\多经验值得我们学习。 本文 Postgresql 是最先进的 Open Source 数据库服务器。它是属于『对象-关连』式的数据库管理系统 (ORDBMS)，目前由一群来自互连网上的开发者 所维护。Postgresql的前身叫做 Ingres，是于 1977 年至 1985 年间由著名的柏克莱大学所发展出来的。Ingres 的程序被 Relational Technologies/ Ingres公司拿去加以改良，并且成为最早成功打入商业市场的关连式数据库系统之一。(Ingres 公司后来被组合国际公司 Computer Associates 所并 购。)在此同时，柏克莱大学的Michael Stonebraker 教授带领一个研究小组发展一个对象关连式的数据库系统叫做 Postgres (1986-1994)。Postgres的 程序被 Illustra 公司拿去发展成一个商业化的产品。(Illustra 公司后来被 Informix 公司并购，程序则整合到 Informix的 Universal Server 去了。)两位柏 克莱的研究生，Jolly Chen 和 Andrew Yu，把 Postgres 加上处理 sql的功能并且易名为 Postgres95(1994-1995)。在他们离开柏克莱后，Jolley 仍然继 续维护 Postgres95，和一个活跃的邮件讨论区。 1996 年夏天，建立一个开放性源代码的 sql 数据库服务器的呼声变得明确而且重要，也应该有一个组人马继续去发展它。在加拿大多伦多的 Marc G.Fournier 提供了一个安装邮件讨论区的主机位置和一个存放所有原始程序码目录的服务器。因此约 1000 个参与邮件讨论的人有了一个新家，另外 一个服务器也设定好，让一部份有登入帐号的人得以透过CVS 将修补程序放入源代码目录中。 Jolly Chen 说∶『这个计划需要用到少数人许多的时间，而不是花许\多人一点点的时间。』的确，以超过二十五万行 C 的程序码而言，我们知道他 的意思。发展初期，有四位主要的成员投入，Marc，来自加州Pasadena 的 Thomas Lockhart，来自俄罗斯 Krasnoyarsk 的 Vadim Mikheev，和我本人 (Bruce Momjian)。我们都各自有一份全职的差事，所以必须利用闲暇之馀来从事开发的工作。这显然是一个很大的挑战。 我们第一个目标是搜寻整个旧的邮件讨论区，找出曾经被张贴出来以修正某些问题的修补程序。当时的系统架构非常脆弱，而且难以了解。在开发 初期的前六个月中，我们深怕某个修补程序可能会毁了系统而我们无法将把它还原回来。许多人反应的问题简直让人抓破头皮，不只是为了想那里 出差错，而且还要思考这个系统到底是如何运作的。 我们继承的是一个很庞大的系统。一个典型的问题反应大概是这样的，『当我做这件事，整个系统都当住了。』我们有一大串类似的报告。很明确 地，一些组织化的工作极待建立。大多数的问题需要深入研究才能解决，而且许多问题是重复的，因此我们建立一个TODO 清单列出所有曾被反应 出有问题的 sql 查询指令。这帮助我们确认问题，而且也让使用者知道已经有这些问题存在，以减少重复的问题被反应出来。我们有许多热心的 开发者，但是要清楚了解系统后端如何运作可要花上不少功夫。许\多开发者投入在系统外围的程序，像是语言接口或是数据库的工具等较容易上 手的东西。其它的开发者专注在某些有问题的查询指令上，以协助找出发生问题真正的地方。令人惊讶的是，许多问题只需要一行C 的程序码就解 决掉了。Postgres 是从学术单位发展而成，尚未经过真实世界中各式各样查询的考验。当时出现一些增加新功能的声音，但系统的不稳定性让我们 仍然决定着眼于错误的改正。 我们把名字从 Postgres95 换成 Postgresql。念起来有点饶舌，但是它突显出系统可以处理 sql 的能力。我们也开始利用 sup 来散布原始程序码， 让使用者可以取得开发中最新的版本而不必每次下载整个套件。稍后我们转换成利用远端的CVS 来做这件事。 每三到五个月就会有一个版本推出。其中包含了二到三个月的开发时间，一个月的 beta 测试，一个正式版本的推出，以及接下来数个星期针对改 正重大错误的小改版。我们从未想过以更积极的排程来推出更多的版本。因为数据库服务器不像一般的文书处理软件或是游戏软件，在出问题时只 要重新启动即可。数据库系统是多人共享的模式，并且把使用者的资料都隐藏在系统内，所以我们必须很小心以确保每一个版本都非常稳定。 开发如此大规模和复杂的程序对新手而言十分困难。面对如此陡峭的学习曲线，我们在吸引开发者加入这个计划上遇到了挫折。尽管如此，我们和 善的气氛，和我们不断改善的稳定性和效能还是吸引到我们所需要的有经验的高手加入。 让我们的开发者具备协助发展 Postgresql 的基本认知被列为第一优先。我们写下一个 TODO 清单记录我们想完成工作的大纲，不过对于一个超过 二十五万行原始程序码的系统而言，任何一个TODO 清单上要做的事都算是一个大计划。我们了解到协助人们从何处着手对开发者的教育有莫大的 助益。我们有一个系统后端模块的流程图，并且简述每个模块的功用。还有一个给开发者看的常见问题集，描述Postgresql 开发者常有共同的疑 问。如此一来，开发者要上手快多了。 从柏克莱所承接而来的原始程序模块分的很清楚，但有些损坏，有些当初在柏克莱写程序的人采用了不当的方法来处理某些特定的工作。每个人写 程序的风格也南辕北辙。我们写了一个工具来把整个原始程序码重新格式化、缩排成统一的格式。我们也写了一个脚本程序以找出原始程序码中固 定会用到的函式，然后把从不曾被呼叫到的函式完全移除。这些动作在每次推出新版前都要做过。一个版本的检查清单提醒我们在每次换版该做些 什么事。 随着对程序的了解与日俱增，我们逐渐尝试更复杂的修改以及新功能的增加。重新设计那些结构不良的程序。我们迈向每一次新版都加入新功\能 的阶段而不再仅有针对问题做修正而己。我们改良系统以符合sql 标准，例如加入 sub-select，改良 locking 机制，增加原本所遗漏一些 sql 的主 要功能。我们还提供商业式的电话服务给需要的人。 Usenet 新闻网络上的讨论群组开始将目光投向我们。在前一年，尽管我们总是迅速地回应使用者的顾虑，但许多人仍然建议改用 Postgresql 以外 的数据库。一年之后，许多人开始推荐Postgresql 给需要 transaction 的使用者，或是需要使用复杂的查询指令，商业等级的 sql 支持，复准的资 料型别和要求系统可靠的使用者。唯有当速度是最优先考量时才会指名其它的数据库。这很明显地壮大了我们的声势。RedHat把 Postgresql 纳入 他们的套件中一同散布更让我们的使用群快速暴增。 现在每一新版本的推出都有大幅的改良。即将推出的 6.5 版是一个里程碑，表示开发团队终于可以完全掌控由柏克莱继承而来的原始程序。现在， 每一个程序模块都至少有一名开发团队的成员可以掌握。感谢这个人数和经验都不断增加的全球性开发团队，如今我们可以轻而易举地新增重要的 功能。如同大多数开放性源代码的计划，我们不知道到底有多少人正在使用我们的软件，但是由我们不断增加的功能，系统的曝光率和邮件讨论区 的通信量可以清楚地的看出，Postgresql将持续成长茁壮。 原文链接：https://www.f2er.com/postgresql/197506.html
