用于记录存储的NoSQL或SQL(即音乐:乙烯基,CD,数字)。

时间:2012-05-31 12:13:09

标签: sql nosql

我正在构建一个唱片店应用程序,并想知道我是否应该采用NoSQL方式或SQL方式。我可以在技术上使用一辆自行车。但我从来都不喜欢推车对音乐类商店的表现......

该模型适用于... ...

发行(标题,价格,EP,LP,主要艺术家,描述)    曲目(标题,价格,主要艺术家,混音艺术家)

非常基本的结构,我可以添加其余的字段,但你明白了......

2 个答案:

答案 0 :(得分:2)

NoSQL解决方案通常更容易入手,但未来可能更难以优化。你从缺乏数据模式中获得的自由可能会转变并咬你 - 你可能会发现自己会随着应用程序的发展而使用不同结构的不同代数的记录,除非你付出额外的努力来保持旧记录的结构是最新的。 / p>

SQL解决方案通常更加严格,需要事先进行更多规划,但另一方面,它们是相当成熟的技术,它们强制执行数据结构,并专门设计以保持一致。

我会在你的情况下选择SQL,因为一个唱片商店将拥有大部分长期存在的数据,这将受益于强加于它的稳定结构。在我看来,NoSQL更适合处理非常短暂的数据的应用程序,你不关心旧数据的完整性和结构(例如聊天,游戏记分牌等)。

答案 1 :(得分:2)

有很多因素可以推动决策。

我在一开始就问自己关于数据的一些问题是:

我的数据有多大可能增长?数据库是否应仅保留市场上的库存或所有可能的标题?我假设您的数据库将有比您提到的两个更多的表。

可能的答案:通过在开始时选择NoSQL结构,您可能会感谢您,因为它后来提供了良好的可扩展性范围。

我的数据有多复杂?多值列是否有可能?

例如,如果你有一个艺术家表,你可能希望这个表有一个发布列,其中存储了该艺术家的多值重新发布ID,以便于对你的发布表进行交叉引用。在这种情况下,NoSQL类型的数据库(如多值数据库)可能会很有趣,因为您可以避免性能损坏的连接。随着数据的增长,数据检索速度可能优于SQL路由。

根据您选择的SQL数据库,还需要查看成本方面。

如果你选择了NoSQL路线,那么这条路线所提供的灵活性需要从一开始就采用良好的初始数据设计进行备份,这样灵活性就不会成为你的敌人。

希望有所帮助。