mysql此架构听起来是否更适合面向文档的数据存储或关系式？

免责声明：让我知道这个问题是否更适合serverfault.com

我想存储有关音乐的信息,特别是：

>类型
>艺术家
>专辑
>歌曲

此信息将在Web应用程序中使用,我希望人们能够看到与专辑关联的所有歌曲,与艺术家关联的专辑以及与流派关联的艺术家.

我目前正在使用MySQL,但是在决定切换之前,我想知道：

>水平缩放有多容易？
>是否比基于SQL的解决方案更容易管理？
>我想要存储的上述数据是否太难于不使用模式？
>当我想到联想时,我立即想到了RDBMS.数据可以存储在CouchDB之类的东西中,但是仍然具有如上所述的某种关联吗？
>我的Web应用程序需要复制,CouchDB或其他应用程序处理得如何？

解决方法:

这种信息非常适合于文档数据库.与许多现实世界数据一样,它并不是天生的关系,因此将其角化为关系模式会带来麻烦(即使使用ORM,我还是从经验中讲). Ubuntu已经在其One product中使用CouchDB来存储音乐元数据以及其他内容.

其余问题一一解答：

>水平缩放比RDBMS更容易.这是Facebook,Digg和LinkedIn等大型网站使用或正在积极研究无模式数据库的众多原因之一.例如,借助称为Eventual Consistency的概念,分片(将数据划分到系统中的不同节点上)可以很好地工作.即,数据可能在一段时间内在各个节点之间不一致,但最终将解析为一致状态.
>这取决于您所说的“管理”的意思…安装通常快速且容易完成.没有用户帐户可以配置和保护(通常在应用程序的业务逻辑层中完成此操作).实时处理文档数据库可能会很有趣：例如,CouchDB中没有临时查询.您必须使用Futon UI或通过HTTP请求与其通信.但是,MongoDB不支持即席查询.
>我不应该这样. Bastien的答案提供了一个JSON文档序列化一些数据的很好的例子.无模式数据库的优点在于,一个文档中可能缺少字段,而另一文档中却存在字段,或者文档之间可以完全不同.这消除了与RDBMS的null值有关的许多问题,这些问题是多种多样的.
>是的；关联存储为嵌套文档,这些文档在您的应用程序中被解析为对象引用,集合等.在Bastien的答案中,“歌曲”键标识一系列歌曲文档.
>这与您关于水平缩放的第一个问题非常相似(水平缩放和复制是交织在一起的).正如CouchIO博客文章Bastien提到的那样,“复制…从一开始就被植入CouchDB中.”我的理解是,所有文档数据库都能很好地处理复制,并且比在RDBMS中进行设置更容易.

如果您决定要将歌曲文件本身与元数据一起存储,则也可以通过将歌曲文件作为文档的附件提供在CouchDB中进行.此外,这样做不会导致任何模式不一致,因为没有模式！

我希望我在这里没有犯太多错误.我本人对记录DB还是很新的.