我正在开发一个项目，我必须保存好友列表。经过深思熟虑并在网上搜索最佳方式，似乎将用户ID和朋友ID保存在表格中。 但可以肯定的是，如果项目预计达到大规模，这种方法似乎并不是很好。 大多数像Google，Facebook，Twitter这样的大型公司也将其功能转移到了nosql数据库。 那么似乎我们不应该从这些NoSQL数据库开始我们的项目吗？
但与此同时我读过NoSQL中有很多编码工作，因为这里没有提供关系数据库中的许多默认服务（如果错了就纠正我）
也许一种方法可以用关系开始，因为它在小规模上具有非常好的功能，然后转移到NoSQL但是为此你必须编写非常好的可移植代码，其中ORM可以起到很好的作用？
希望其他人能够采取正确的方法来做到这一点吗？
答案 0 :(得分：4)
一般不要使用ORM，特别是ActiveRecord。
他们通常创建一个'开发债务'，这意味着它使项目的开始看起来很容易。
当你投入与ORM的完全整合并且80％的项目完成后，你开始看到ORM掉落的所有边境案例。
除此之外，大多数ORM都会进行次优查询，从不利用特定于引擎的功能。
至于SQL vs noSQL：我建议从SQL数据库开始，然后当应用程序增长时，开始使用一些缓存策略（memcached，或者redis）。只有当该解决方案耗尽时 - 才开始寻找不需要关系的数据库逻辑部分。
noSQL数据库提供了非常具体的用例列表，并不适用于普通应用程序。
答案 1 :(得分：3)
使用SQL数据库。
当您每天开始吸引数百万用户时，请开始使用某种NoSQL数据库。
答案 2 :(得分：2)
编辑 我看到其他人建议从SQL开始。我想改变我的主张并说 - 尝试小规模项目，如“小型推特克隆”或“带录像带的商店”。将数据库保存在许多节点上并编写脚本，这些脚本将充斥您的数据。使用Riak / Cassandra然后使用一些SQL解决方案。你会发现自己更容易，更快捷。 /编辑
我会选择NoSQL（这就是我现在正在做的事情。之前我在大型项目中使用过MySQL）。为什么？它使用起来要简单得多，因此您可以更加关注其他重要事项（NoSQL会处理大多数数据存储问题）：
您不必定义架构，这也意味着您不必升级它。在MySQL中，由于系统升级，我长时间停机。添加单列/索引需要花费大量时间。表只有几百万行。
您可以在几分钟内运行，分布式环境。在MySQL中，您必须在几台机器之间手动分割数据（除非您将所有内容保存在一台不是一个好主意的机器上）。
你的表现要好得多。用MySQL表现真的很糟糕。没有memcached就行不通。 Memcached是一个分布式键值存储（简单的NoSQL数据库）。显然，使用memcached会花费额外的时间来优化查询
您不必考虑规范化/非规范化
查询很简单（至少在键值存储中）。你只是不关心这样的事情：我应该使用“where UserId = 12345”或“where UserId ='12345'”（在MySQL中，其中一个不使用索引！）。
如果一台NoSQL计算机出现故障，那么您的应用程序中并不关心它。查询将在另一个副本上执行（您不必实现此操作！）
使用NoSQL还有缺点
你没有获得ACID。在大多数情况下，你根本不需要！
此外，还有更多开发人员熟悉SQL解决方案。另一方面，NoSQL解决方案要简单得多（至少在我的经验中），所以你不需要经过认证的数据库管理员（一个解决你的数据库问题的魔术师，只有他知道它的工作原理）
您无法进行某些查询 - 例如连接不存在，但如果您没有规范化数据，那么连接就没用了（您可以节省时间，因为您不必考虑规范化）
好文章： http://labs.mudynamics.com/2010/04/01/why-nosql-is-bad-for-startups/
我的建议是从NoSQL开始并坚持下去。您应该查看基于发电机的数据库，如Riak和Cassandra。还可以尝试CouchDB（CoachBase）。这适用于大多数数据。对于朋友关系图数据库是不错的选择。
答案 3 :(得分：1)
我不认为ORM对你有多大帮助，nosql数据库的哲学与关系数据库的哲学完全不同。因此，一旦你开始使用关系并在模式中投入大量精力并使用外键之类的东西，你将不得不将它移动到nosql。反过来也是如此。
你提到过的大公司正在使用nosql，因为它提供了高吞吐量和数据库模式的简单性，考虑到它缺少关系数据库提供的一些高级功能。
对于他们的帐户，他们使用关系数据库，我确信： - ）
最后它将取决于您的架构的复杂性：如果它很简单，请尝试nosql：更容易设置，实际上您根本不需要定义架构，只需设置记录（或文档为他们中的一些人称之为）并保存它。如果您改变对表结构的看法，则无需更改表：只需保存数据。容易：这就是为什么它今天如此出现。
但是没有参照完整性，对交易也有一些限制，并非一切都得到支持。因此，如果您在数据库架构，数据完整性，事务方面需要更多，请转到关系数据库。
答案 4 :(得分：1)
我在生产中使用MongoDB，Riak和其他一些NoSQL解决方案已有一段时间了。 我认为从一开始就使用NoSQL解决方案的最大好处是思考过程，你不会受限于他们在大学教授的关系数据模型，这使你更倾向于根据需要调整数据而不是调整你的需求。应用程序以适合您的数据表示。
那就是说，我认为过早扩展可能不是一件好事，如果你正在构建一个新的Web应用程序（或一些大数据应用程序），通常需要一些时间，直到你达到任何需要NoSQL的限制（带宽） ，记忆，表现......）
我能给你的最好的建议是用数据模型（而不是ORM）抽象构建应用程序，例如，如果你想从user_id获取朋友列表，我会为“朋友存储”构建一个接口通过保持良好的抽象，它将具有fetch_friends(user_id):friend_ids的方法，您可以在需要时替换底层实现。
我自己在存储用户数据时使用了这种方法。开始使用MongoDB（我的数据是无模式的）当单个服务器的负载变得太多（在MongoDB有适当的分片之前）转移到Riak并且当需要更好的SLA用于客户端时（Riak不是那么可靠）转向一些适当的解决方案。 每一步都需要在开发和集成时间上花费很大的开销，但到那时我们有资源做出这样的举动。
恕我直言，如果我是你，我会从MySQL开始，这样我就不需要考虑耐久性或一致性或持久性，并在碰到碰撞时将其换掉。
答案 5 :(得分：0)
SQL与NoSQL审核：http://www.sigmod.org/publications/sigmod-record/1012/pdfs/04.surveys.cattell.pdf
“可扩展的RDBMS因此具有优于NoSQL数据存储的优势，因为您可以方便地使用更高级别的SQL语言和ACID属性，但只需为跨越节点的用户付出代价。”
答案 6 :(得分：0)
playOrm允许您将关系数据存储在noSQL存储中，并且仍然允许该数据随着系统的增长而扩展，因此具有两全其美的优势。