什么是更优化的数据库设计方式?
我正在构建一个应用程序，其中不同的公司注册和添加他们的用户和使用应用程序。每个帐户最多需要10张表。如
table1, table2, table3..table10
这就是我目前正在做的事情，有10个表，并将所有帐户的所有信息存储到这些表中。但我想到了一个横向扩展数据库设计的想法。我们的想法是，每当有人创建公司帐户时，我的应用程序将动态创建这些表，如下所示:
c_31_table1, c_31_table2, c_31_table3...c_31_table10
其中31为加入公司的示例accountid ?我的假设是，因为SQL只是垂直增长，否则随着时间的推移，它会变得很慢，将来每个表大约有40k条记录或更多。因此，这种方法将保持数据库的垂直长度较低，并水平缩放。
这个技术是一个很好的优化技术吗?
通常不是个好主意。每个情况都是不同的。这样，您就不会从查询缓存中获益(同样多)。您的查询需要预先进行更多的工作(不多)。而存储过程、函数和事件则需要CONCAT s、PREPARE、EXECUTE和DEALLOCATE PREPARE。
适当的索引和多租户应该是你的重点，直到你有一个问题，这可能是很长一段时间。我会把重点放在这里，并在开发过程中使用EXPLAIN输出。分析代码。永远要做侧写。找出程序运行缓慢的地方并修复它们。
你提出的解决方案会有一堆乱七八糟的东西。他们不容易清理自己。而且，DDL调用并不便宜，即使偶尔也不便宜。
如果我工作的地方突然想给表命名为
c_31_table1, c_31_table2, c_31_table3...c_31_table10
我认为这种方法是一种"早期优化"。
对于只有40k行的单个"公司"本身不会造成任何显著的负载。即使当前负载不需要它，你也会用你的优化效果"毒害"你的应用程序代码。
当公司数量增加时，可能需要引入一些优化(在公司数量远远超过1000家之前可能不会)。那么你可以考虑将分区作为减少"垂直"长度的一种方法。
但是要保持应用程序不受此类优化的影响。否则，您将在应用程序的整个生命周期中付出高昂的代价。
另一个方面:
允许DDL调用将暴露您可能不希望暴露的特权。