我想存储类似于jsfiddle商店代码的代码。我目前使用Postgres作为我的主数据库，但我想知道是否更适合使用NoSQL数据库？什么nosql数据库是理想用于存储代码/片段？
现在的代码片段只有一个作者，但将来可能会有多个作者，我也希望恢复的能力。
我知道有关键/价值数据库和面向文档的数据库。哪个特定的noSQL数据库可以满足我的需求？还是应该坚持使用我的Postgres数据库？
FYI：
您不能选择非关系数据策略，而无需定义您想要对数据执行的操作。
关系数据库设计来自规范化规则，您可以在知道自己的数据后应用这些规则。但非关系数据库设计依赖于您的查询而不是您的数据。
但是，如果不知道你的应用程序，我的第一个建议是坚持使用PostgreSQL。将代码片段存储在文本blob中，并将代码的元数据（作者身份，日期，语言，项目等）存储在文本blob旁边的其他列中。你也可以考虑使用GIST索引来实现灵活的搜索。
您也可以考虑Apache Solr，它在技术上类似于面向文档的DBMS，尽管它通常以全文搜索引擎的形式提供。
至于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）
听起来像一个相对不复杂的应用程序，可以在传统的关系数据库或NoSQL中实现，没有太多问题。
但是，如果您要在PostgreSQL中保留用户基本信息，那么将其作为单一存储方法坚持下去似乎是最简单的。使用SQL数据库和，NoSQL增加了复杂性，使数据集之间的连接更加困难（例如，您无法进行查询以执行“列出用户及其最近文档”这样的查询），并且使其无法完成以确保两个数据集之间的一致性。
你得到了什么麻烦？你想要版本控制。 CouchDB将为您提供版本控制，但是您是否应该将其用于UI级别的版本控制（例如，因为压缩数据库将丢失旧版本），这是值得怀疑的。
你说得对 - 我应该坚持使用PostgreSQL，除非我有需要保证NoSQL数据库。当事情变得更加复杂时，我将能够提供一些真实的信息来获得关于缩放和重构的建议。 – 2010-09-29 23:57:17
对于如何在postgres中实现版本控制，我有点无知，但我从来没有做过。我将不得不制作一个*所有*代码片段的表格和一个表格，其中包含“发布”或“粘贴”号码的主键，其中包含元数据并包含“活动”或最新代码段的外键，对？编辑：我正在提出这个新问题。 – 2010-09-30 00:05:44