Quelle base de données nosql est idéale pour stocker du code/des snippets?

Question

Je veux stocker le code semblable à comment jsfiddle stocke le code. J'utilise actuellement Postgres pour ma base de données principale mais je me demande s'il est plus idéal d'utiliser une base de données NoSQL?

Les extraits de code pour l'instant auront un seul auteur, mais dans le futur il peut y avoir plusieurs auteurs et je veux aussi la possibilité de revenir en arrière.

Je sais qu'il existe des bases de données clé/valeur et des bases de données orientées document. Quelle base de données spécifique à noSQL répondrait à mes besoins? Ou devrais-je encore coller avec mon Postgres db?

Pour votre information:

1. J'utilise django
2. Les utilisateurs seront stockés de façon permanente dans Postgres (j'utilise openID)

Answer 1

Vous ne pouvez pas choisir une stratégie de données non relationnelle sans définir ce que vous voulez faire de vos données.

La conception de base de données relationnelle provient des règles de normalisation, que vous pouvez appliquer une fois que vous connaissez vos données seules. Mais la conception de base de données non relationnelle dépend plus de vos requêtes que de vos données.

Mais sans rien savoir de votre application, ma première recommandation serait de rester avec PostgreSQL. Stockez vos extraits de code dans des blobs de texte et des méta-données sur le code (auteur, date, langue, projet, etc.) dans des colonnes supplémentaires à côté du texte blob. Vous pouvez également envisager d'utiliser les index GIST pour permettre une recherche flexible. Vous pouvez également considérer Apache Solr, qui est techniquement similaire à un SGBD orienté document, bien qu'il soit généralement présenté comme un moteur de recherche fulltext.

Answer 2

En ce qui concerne les bases de données NoSQL, les seuls que je Je suis familier avec XML (ne pas bien évoluer et a une mauvaise concurrence), et les bases de données locales telles que Paradox, dBase, FoxProx et Access. Je ne recommanderais aucun d'entre eux. Je pense que l'idée que c'est une base de données NoSQL devrait être un facteur plus petit dans votre décision. Considérez ces choses à la place.

• Redondance. Pouvez-vous l'exécuter sur deux serveurs en même temps ou prend-il en charge le basculement? (SQL Server, Interbase, Firebird)

• La concurrence. Hébergerez-vous cette application sur le Web? Comment va-t-il gérer 10 opérations simultanées? (PostGres, MySql, Interbase, Firebird)

• Vitesse. Combien de temps est acceptable pour une recherche ou un article?

• Embeddabilité. Est-ce une application de bureau? Une base de données intégrée peut faciliter les choses. (Bases de données locales telles que Paradox, dBase, FoxPro, Access, Interbase, Firebird ou SQLite)

• Portabilité. Les applications de bureau peuvent fonctionner sur Mac, Linux, Windows. (SQLite)

Answer 3

Cela ressemble à une application relativement simple qui pourrait être implémentée dans une base de données relationnelle traditionnelle ou un NoSQL sans trop de problèmes.

Cependant, si vous conservez les informations de base utilisateur dans PostgreSQL, il semblerait plus simple de s'en tenir à cela comme une méthode de stockage unique. Si vous utilisez une base de données SQL et, un NoSQL ajoute de la complexité, rend difficile la jonction entre les ensembles de données (par exemple, vous ne pouvez pas faire une requête pour faire la liste des utilisateurs avec leur document le plus récent). assurer la cohérence entre les deux ensembles de données.

Qu'obtenez-vous pour ce problème? Vous voulez le versioning. CouchDB vous donnera le contrôle des révisions, mais il est douteux que vous utilisiez cela pour le versionnement au niveau de l'interface utilisateur (par exemple parce que le compactage de la base de données perdra vos anciennes versions).