我正在做一个类似于社交网络的系统。最多用户数量最多必须为50.000或70.000。
目前我正在使用mysqli +准备好的声明。 ERD现在有30个表，最终可能达到40个表。
所以，我的问题是：我从未使用图形数据库......我已经通过mysql workbench完成了ERD，并且已经开发了一些代码。对于此项目中用户的预期数量，建议从MySQL更改为图形数据库？我的sql代码和数据库模型可以使用吗？这种变化有什么好处？
你觉得怎么样？感谢
答案 0 :(得分：3)
如果您可以访问递归查询（在MySQL中不是这种情况，但在PostgreSQL中可用）并且您的查询涉及最大深度标准，那么当存储在SQL中时，图表会很好并且速度很快（这可能是您在社交网络上的情况），或者如果它们被正确编入索引。
索引图有多种方法。在你的情况下，你的图形可能不是很密集，因为你正在处理几乎独立的多个森林（你通常会处理紧密集群的用户），所以你有很多选择。
最容易实现的是传递闭包（基本上，预先计算所有潜在路径的调用）。在你的情况下，它可能是部分的（例如，深度2或深度-3）。这允许在单独的表中完全索引相关节点，以用于非常快速的图形查询。使用触发器或存储过程使其保持同步。
如果您的图表比这更密集，您可能需要考虑使用GRIPP index。与嵌套集非常相似，如果删除(rgt - lft - 1) / 2 = children属性数，则后者效果最好（如更新最快），并使用lft / rgt的浮点值而不是整数。 （这样做可以避免在插入/移动节点时重新索引图形的整个块。）