我们正在为课程项目设计一个数据库（mysql）。这正是我们陷入的困境：评论和喜欢系统。所以我们发现了这个问题：在数据库中实现评论和喜欢
这是美丽和准确的解释。但每一个喜欢或评论都必须是新的一排。instagram类似的按钮平均每天被点击45亿次。这对我来说太大了 likes table。4.5bx30天=每月135万亿！我不相信他们这样设计。
我们要考虑的主要问题是：我们如何设计大公司使用的最合适的设计结构(twitter、instagram等）（查询执行最少、优化最多等）
我们实际上是这么想的：
如果有人对帖子发表评论，json将在comments列中更新。这种方法比为每个注解或类似内容添加新行更有效吗？
我们发现这个类图：https://stackoverflow.com/a/1120491/5685796 这个设计在2009年被分享。如果我们做的是大型项目，那么实现这个模式是否会为我们将来带来一个优化问题(假设每个分享都有100万条赞和100万条评论
编辑：我们正在设计关系数据库。
1条答案
按热度按时间ajsxfq5m1#
使用一个单独的表进行注解。它将有你指出的5列。
把东西放在json中会使它们很难获取、搜索、过滤等等，对于任何类型的数组也是如此。这两种方法都可以——将一个json对象数组放在一个单元格中。
了解
JOIN为了重新连接我要你分开的东西。要进入万亿级，你还需要“切分”。但在你进入百万富翁之前，我们不要讨论这个问题。
（更多建议）
“大公司”拥有一个数据集，它被“分片”到数百台服务器上。
Comments很可能在一张普通的table上。json不太可能被使用；尤其是没有任何东西可以搜索或分类。json适用于需要保存但不需要搜索/排序的杂项kruft。对你来说
设计和实现一些东西（即使它包含json）；
投产；
研究出现的问题；
在几个月内重新设计-愿意扔掉大部分原来的设计。
“冲洗并重复”。要想达到大公司在十年和几十名工程师之后的成就，有太多的障碍需要跨越。
我一次只能帮你做一次迭代。
喜欢。。。如果你在保留一个计数器，那么就在一个“平行”表中进行。这将降低主表上的争用。如果你把喜欢什么的人列在一张单子上，那就是一张table。
ID。。。不要使用
AUTO_INCREMENT在一张有着完美pk的table上。主要的例子是many:many table --使用两个ID的组合。正常化，但不要过度正常化。这是你将开始理解我的'步骤3'，以上。
不要使用eav（实体属性值）模式设计。它的伸缩性不好。
子类化通常会变得笨拙。在这个链接中，他们有照片/文章/地点“是一个”实体。不。
Photos应该是自己的表，有自己的列、怪癖、索引等。不要使用任何第三方软件。好的，您可以在我上面步骤的第一次迭代中使用它。但在第四步，把它完全扔掉。到那时，你已经被迫学习mysql的细节（因为这个软件不能完全阻止你学习细节）。