我正在构建一个唱片店应用程序，并且想知道我应该采用 NoSQL 方式还是 SQL 方式。从技术上讲，我可以使用自己的购物车。但我从来没有真正喜欢过推车在音乐类商店中的表现......
该模型类似于...
发行（标题、价格、EP、LP、主要艺术家、说明） 曲目（标题、价格、主要艺术家、混音艺术家）
非常基本的结构，我可以添加其余字段，但你明白了......
问问题
590 次
2 回答
3
NoSQL 解决方案通常更容易开始，但将来可能更难优化。您因缺乏数据模式而获得的自由可能会反过来影响您 — 随着应用程序的发展，您可能会发现自己拥有不同结构的不同代记录，除非您付出额外的努力来使旧记录的结构保持最新。
SQL 解决方案通常更严格，需要事先进行更多计划，但另一方面，它们是一项相当成熟的技术，它们强制执行数据结构，并专门设计用于保持其一致性。
在您的情况下，我会选择 SQL，因为记录存储将主要包含长期存在的数据，这将受益于强加于它的稳定结构。在我看来，NoSQL 更适合处理非常短暂的数据的应用程序，在这些应用程序中，您不太关心旧数据的完整性和结构（例如聊天、游戏记分牌等）。
于 2012-05-31T12:22:40.627 回答
3
有很多因素可能会以任何一种方式推动决定。
一开始我会问自己关于我的数据的一些问题是：
我的数据有多大可能增长？数据库应该只保存有库存的还是市场上所有可能的可用标题？我假设您的数据库将拥有比您提到的两个更多的表。
可能的答案：通过一开始就选择 NoSQL 结构，您可能会感谢自己后来为良好的可扩展性提供了范围。
我的数据有多复杂？多值列有潜力吗？
例如，如果您有一个艺术家表，您可能希望此表有一个发布列，该列存储该艺术家的多值发布 ID，以便轻松交叉引用您的发布表。在这种情况下，诸如多值数据库之类的 NoSQL 类型的数据库可能会很有趣，因为您可以避免对性能造成损害的连接。随着数据的增长，数据检索速度可能比走 SQL 路线更好。
根据您选择的 SQL 数据库，还需要考虑成本方面。
如果你确实走 NoSQL 路线，那么这条路线提供的灵活性需要从一开始就以良好的初始数据设计为后盾，这样灵活性就不会在以后成为你的敌人。
希望有帮助。
于 2012-05-31T13:05:06.087 回答