Est-ce que ce schéma sonore mieux adapté pour un magasin de données orienté document ou relationnel?

Question

Avertissement: laissez-moi savoir si cette question est mieux adaptée pour serverfault.com

---

Je veux stocker des informations sur la musique, en particulier:

• genres
• Les artistes
• albums
• chansons

Cette information sera utilisée dans une application web, et je veux que les gens puissent voir toutes les chansons associées à un album et albums associés à un artiste, et les artistes associés à un genre.

J'utilise actuellement MySQL, mais avant de prendre une décision de passer je veux savoir:

1. Comment facile est mise à l'échelle horizontale?
2. Est-il plus facile à gérer qu'une solution SQL?
3. Est-ce que les données ci-dessus, je veux stocker trop difficile à faire sans schéma?
4. Quand je pense association, je pense immédiatement SGBDR; peuvent être données stockées dans quelque chose comme CouchDB, mais ont encore une sorte d'association comme indiqué ci-dessus?
5. Mon application Web nécessite la réplication, comment bien CouchDB ou d'autres gérer cette situation?

Answer 1

Ce type d'information est parfaitement adaptée aux bases de données de documents. Comme avec beaucoup de données réelles, il est par nature relationnelle, donc chaussure écornage dans un schéma relationnel apportera des maux de tête en bas de la ligne (même en utilisant un ORM - je parle d'expérience). Ubuntu utilise déjà CouchDB pour stocker les métadonnées de la musique, ainsi que d'autres choses, dans leur Un produit .

Prendre le reste de vos questions une par une:

1. mise à l'échelle horizontale est WAY plus facile que de SGBDR. Ceci est l'une des nombreuses raisons de grands sites tels que Facebook, Digg et LinkedIn utilisent, ou enquêtent activement, les bases de données de schéma-moins. Par exemple, sharding (divisant vos données sur différents nœuds dans un système) fonctionne à merveille grâce à un concept appelé cohérence dans le temps ; à savoir, les données peuvent être incompatibles entre les nœuds pendant un certain temps, mais elle finira par se résoudre à un état cohérent.
2. Cela dépend ce que vous entendez par « gérer » ... L'installation est généralement rapide et facile à remplir. Il n'y a pas de comptes utilisateur pour configurer et sécuriser (ce qui est plutôt fait généralement dans la couche logique métier de l'application). Travailler avec un document DB en temps réel peut être intéressant: il n'y a pas ad hoc dans l'interrogation CouchDB, par exemple; vous devez utiliser l'interface utilisateur ou futon communiquer avec lui via des requêtes HTTP. MongoDB, cependant, ne supporte des requêtes ad hoc.
3. Je ne devrais pas penser. La réponse de Bastien fournit un bon exemple d'un document JSON sérialisation des données. La beauté des blocs de données est que sans schéma champs peuvent être absents d'un document et présente dans un autre, ou les documents peuvent être complètement différents les uns des autres. Cela élimine la plupart des problèmes liés à la valeur null « SGBDR, qui sont nombreuses et variées.
4. Oui; les associations sont stockées sous forme de documents imbriqués, qui sont analysées dans votre application en tant que références d'objets, collections, etc. Dans la réponse de Bastien, la touche « chansons » identifie une série de documents de chanson.
5. Ceci est très similaire à votre première question sur l'échelle horizontale (mise à l'échelle horizontale et la réplication sont intimement liés). Comme le blog CouchIO Bastien mentionné déclare: « La réplication ... a été cuit dans CouchDB depuis le début. ». Je crois comprendre que toutes les bases de données de documents gèrent bien la réplication, et le font plus facilement que de le mettre dans un SGBDR.

vous deviez vous décider vouliez stocker le fichier lui-même de la chanson ainsi que les métadonnées, vous pouvez le faire aussi dans CouchDB, en fournissant le fichier du morceau en tant que pièce jointe au document; De plus, vous n'avez des incohérences de schéma en raison de le faire, parce qu'il n'y a pas de schéma!

J'espère que je ne l'ai pas fait trop de faux pas ici; Je suis tout à fait nouveau pour moi documenter BDs.

Answer 2

Vos données semble idéal pour les bases de données orientées document.
Exemple de document:
{
"type":"Album",
"artist":"ArtistName",
"album_name":"AlbumName",
"songs" : [
{"title":"SongTitle","duration":4.5}
],
"genres":["rock","indie"]
}

Et la réplication est l'un des plus cool CouchDB ( http://blog.couch.io/post/468392274/whats-new-in-apache-couchdb-0-11-part-three-new )
Vous pouvez également voulez jeter un oeil à Riak.