《PostgreSQL服务器编程》一一2.1　购置成本

本节书摘来自华章计算机《PostgreSQL服务器编程》一书中的第2章，第2.1节,作者：（美）Hannu Krosing, Jim Mlodgenski, Kirk Roybal 著
，更多章节内容可以访问云栖社区“华章计算机”公众号查看。

当我们决定在应用队列中采用何种技术时，一个最大的考虑因素是购置成本。我见过许多画在白板上的应用架构。他们的技术团队会害羞地向我展示白板上的应用架构，但他们会通过试图降低软件许可成本，而证明设计的合理性。当谈到数据库环境的时候，我们通常的考虑对象有Oracle、SQL Server、MySQL和PostgreSQL。Oracle作为数据库领域的主导者，也是最昂贵的数据库产品。在低端市场，Oracle确实有价格合理的产品，甚至免费的Express版本，但都是受限制的。大多数人都会需要低价产品之外的功能服务，如此他们就会考虑购买Oracle的企业版。这样通常就会大大提高购置成本，CFO看到这个报价就会暴跳如雷，而你也就只能乖乖地回去重新设计你的解决方案，削减你的许可成本。
紧接着我们谈谈微软的SQL Server。这是第一个合理可行的选择。Microsoft网站已经列出了它的报价。此处不再赘述，因为报价单内容实在过多，完整列举会让本书的印刷时间至少延长5分钟，不过，SQL Server采购成本的经验标准大概在5000美元，这个采购标准就足以让你运行一个网络能力模型。这个价格并不包括服务合约。在整个开发成本的预算中，这个报价应该还算是合理的，并没有太高的进入门槛。
然后，我们再谈到开源产品，它们是MySQL和PostgreSQL 。两者没有任何的成本，服务合约成本也为零。这是一个非常具有挑战的采购成本。
还记得我在本章开头聊到的，那些项目启动之后你还不清楚的事情吗？这里就是真正的过人之处。
你能承受失败。
这也就是我想说的事情！
低采购成本是一个低失败成本的代名词。当我们为项目增加了所有各种未知项的时候，我们发现，在我们面前出现了一个相当好的机会，这个机会就是如果第一次迭代将不能满足市场的需求，我们需要有一种方法来快速抛弃它，没有长期合约，也不需要启动一个新项目而产生额外的费用。
如此，继第一个版本之后，项目经理从消费者那里汲取教训，继续下一个版本的开发迭代。在理想状态下，我们希望这个用户满意度的经验积累仅由非常低的成本换取回来，如此这个项目才可以开始茁壮成长。项目的后续版本才能大胆设计，并开始一个新的篇章——实际情况本该如此，你不能将项目的成功寄希望于第一个版本的完美诞生。你绝对不能。