我想存储类似于jsfiddle存储代码的代码。我目前使用Postgres作为我的主数据库，但我想知道使用NoSQL数据库是否更理想？
现在的代码片段只有一位作者，但将来可能会有多位作者，我也希望能够还原。
我知道有关键/价值数据库和面向文档的数据库。哪个特定的noSQL db可满足我的需求？或者我还应该坚持使用我的Postgres数据库吗？
仅供参考：
答案 0 :(得分：1)
对于NoSQL数据库，我唯一熟悉的是XML（不能很好地扩展并且具有错误的并发性），以及本地数据库，如Paradox，dBase，FoxProx和Access。我不会推荐任何这些。
我认为这是一个NoSQL数据库的想法应该是你决定的一个小因素。请考虑这些事情。
冗余。您可以同时在两台服务器上运行它还是支持故障转移？ （SQL Server，Interbase，Firebird）
并发。你会在网上托管这个应用程序吗？它将如何处理10个并发操作？ （PostGres，MySql，Interbase，Firebird）
速度。查找或发布可以接受多长时间？
嵌入性。这是桌面应用程序吗？嵌入式数据库可以简化操作。 （本地数据库，如Paradox，dBase，FoxPro，Access，Interbase，Firebird或SQLite）
可移植性。桌面应用程序可以在Mac，Linux，Windows上运行。 （SQLite的）
答案 1 :(得分：1)
如果不定义要对数据执行的操作，则无法选择非关系数据策略。
关系数据库设计来自规范化规则，只有在您了解数据后才能应用。但非关系数据库设计比您的数据更依赖于您的查询。
但是在不了解您的应用程序的情况下，我的第一个建议是坚持使用PostgreSQL。将文本blob中的代码片段以及有关代码（作者，日期，语言，项目等）的元数据存储在文本blob旁边的其他列中。您还可以考虑使用GIST索引来进行灵活搜索。
您可能还会考虑Apache Solr，它在技术上类似于面向文档的DBMS，尽管它通常作为全文搜索引擎呈现。
答案 2 :(得分：1)
听起来像一个相对简单的应用程序，可以在传统的关系数据库或NoSQL中实现，而不会出现太多问题。
但是如果你在PostgreSQL中保留用户群信息，那么将它作为单一存储方法坚持下来似乎是最简单的。使用SQL数据库和，NoSQL增加了复杂性，使得难以连接数据集（例如，您无法进行查询以执行“列出用户及其最新文档”之类的操作） ，并且无法确保两个数据集之间的一致性。
你遇到了什么麻烦？你想要版本化。 CouchDB将为您提供版本控制，但是您是否应该将其用于UI级版本控制（例如，因为压缩数据库将丢失旧版本）是值得怀疑的。