<p>相信很多开发者都有个疑问，如果以一种简单、灵活的方法来存储程序数据，应该选择NoSQL还是SQL呢？</p>    <p>NoSQL数据库提供了非常完美的体验：一个安装包，启动数据库，使用JSON API进行数据读写操作。此外，NoSQL支持快速迭代。</p>    <p>SQL方案需要更多的预先投资：配置服务器，插入数据，设定数据表，以对象关系映射系统来进行数据获取。</p>    <p>两者对比权衡，创业公司更青睐NoSQL。那么要拥抱NoSQL，需要经历哪些阶段呢？</p>    <p><strong>阶段一：排除</strong></p>    <p>决定使用NoSQL便意味着你做出了两个重要决定：无需ACID事务和无需一个架构。这看起来是无害的，但是其结果会对程序产生深远影响。</p>    <p>排除的第一种形式是你不需要ACID事务。这在应用的早期阶段常见，但是随着用户规模增长，事务处理的逻辑能力将会使你的程序更易于运作。所以完全放弃事务是不可取的。</p>    <p>排除的第二种形式是不需要架构。这意味着程序可以有效处理数据间的逻辑，而无需借助传统关系型数据库的关系处理能力。</p>    <p><strong>阶段二：愤怒</strong></p>    <p>NoSQL数据库的设计目的是在分布式机器集群中取得连续性和可用性的平衡。因此，你不得不使用复杂的分布式算法来进行协调，同步和错误处理。</p>    <p>某天当你发现数据丢失而愤怒不已时，将发现事务和架构是多么重要。</p>    <p><strong>阶段三：商讨</strong></p>    <p>当愤怒消退后，或许你会尝试把事务和架构补充回NoSQL中。首先是为应用程序编写事务管理器。但是交易系统通常很庞杂，模块之间相互依赖，涉及到并发控制，错误恢复和权限访问。你可能会成功，但最终的结果将很难进行扩展或维护。</p>    <p>第二个方法是使用复杂组织条件和处理来增强数据整合，确保数据完整性。这些规则嵌入在应用程序逻辑并需要传达给每个使用该数据库的开发团队。</p>    <p><strong>阶段四：沮丧</strong></p>    <p>当为你找出一个可行的事务处理方案和一个临时的架构处理方案时，你可能发现你的NoSQL不能很好地处理其它需求。它不能联接表，不能对记录进行分组，更不必说复杂的查询。这时你会变得沮丧，试图寻求集群运维专家的帮忙。</p>    <p><strong>阶段五：接受</strong></p>    <p>看来NoSQL也有其不足之处。最后接受这个事实，你批判性地评估自己的数据库解决方案。你试图区分数据中哪些属于关系型哪些不属于关系型。最终，找出一个使NoSQL和关系型数据库友好共处的方案：扩展关系型满足一部分需求，扩展NoSQL满足另外一部分需求。</p>    <p>被媒体广泛宣传的新技术，必须经过个人实践，找出适合自己的部分才是有价值的；否则，拔苗助长，生搬硬套只会徒增烦恼。</p>    <p> </p>    <p> </p>    <p> </p>    <p>来自：http://geek.csdn.net/news/detail/105774</p>    <p> </p>