我目前正在构建一个为用户提供大量排序选项的网站，我希望以一种可以扩展而无需太多头痛的方式构建它。当然，对这两种技术都有一些权衡，但我很想听听你的意见。
1）将序列化的json数组存储在单个列中。添加或删除新条目时，将对json进行解码，操作数组，然后在数据库中重新编码和更新。数据将使用数组排序函数在PHP的站点上排序，或者在某些情况下，MySQL的“IN”将用于根据id列表选择条目。
这种方法的主要问题是开发时间增加，以及将自己编入角落的风险。如果json字符串需要更改，或者我想添加新功能，那可能会非常痛苦。我也不知道这将如何在负载下执行，总是为每个用户选择并更新一个大的json字符串。
2）为每个新条目执行插入的经典RDBMS方法及其与用户/条目的关系。然后使用JOIN选择。将仔细设置索引，并使用EXPLAIN确保每个JOIN选择都是优化的。
有很多关于摆脱RDBMS的讨论。但这种谈话通常来自获得数百万用户的网站。关于这一点的好处是开发将很快并且如果将来需要添加新数据，则很容易改变表格。
首次编写应用程序时，我是否应该担心缩放？或者我应该专注于产品，尽早发布，并在我去的时候调整规模？
谢谢，我期待着您的意见！
答案 0 :(得分：2)
我认为你不应该担心，如果你不知道你将以什么规模来优化你的应用程序。
解决方案1）听起来不是很好。如果您想使用类似的东西，您应该使用非关系型数据库，例如CouchDB（我今天刚刚找到它nice tutorial）因为它立即存储JSON（并且您可以排序和使用JavaScript中定义的视图选择它。它不仅适用于拥有数百万用户的网站（尽管它确实非常容易扩展）。您应该自己尝试一下，不要考虑它周围的所有“嗡嗡声”和反“嗡嗡声”，看看它是否对您的应用程序有用。
也许你应该选择RDBMS。它们仍然非常快（如果你喜欢组织和搜索Facebook 50TB的收件箱数据，你可能会遇到麻烦），你会惊讶于正确定义的索引可以为性能做些什么。并且有很多RDBMS知识和良好的工具，因此它非常易于使用。
在设计良好的应用程序中，您无论如何都应该能够轻松地切换底层数据库实现。