动态创建表作为分区的一种方式：好还是坏做法？

应用程序动态创建数据库表作为分区的手段是否合理？动态创建表作为分区的一种方式：好还是坏做法？

例如，假设我有一个大表“widgets”，其中有一个标识每行所有者的“userID”列。如果这个表格变得非常大，那么让应用程序为每个新用户创建一个名为“widgets_ {username}”的新表格会有意义吗？假设应用程序一次只需查询属于单个用户的小部件（即不需要尝试将这些用户小部件表中的任何一个连接在一起）。

这样做会将一张大桌子拆分为更容易管理的块，但这看起来不是一个优雅的解决方案。在我看来，应该在应用程序写入时定义数据库模式，并且任何运行时数据都以行的形式存储，而不是作为附加的表存储。

作为一个更普遍的问题，在运行时修改数据库模式可以吗？

编辑：这个问题大多是假设的;我有一个非常好的感觉，即在运行时创建表没有任何意义。这就是说，我们的应用程序中有一个包含数百万行的表格。 SELECTs表现良好，但删除特定用户拥有的所有行可能需要一段时间。基本上我正在寻找一些可靠的推理，为什么只是为每个用户动态创建一个表格对于我什么时候被问到什么都没有意义。

来源

2011-08-19 fizban

为什么你认为一个拥有大量小部件 - 用户名表的数据库比一个带有额外列“用户名”的表更好？使用后者，并使用正确的索引。 – Konerak

为什么还要打扰？是SELECT * FROM部件WHERE userID ='Fulano'需要很长时间才能运行？ –

“轻松管理”是什么意思？你在谈论查询表格还是存档等任务？ –

NO，NO，NO !!现在重复我之后，I will not do this because it will create many headaches and problems in the future!数据库被用来处理大量的信息。他们使用索引来快速找到你在做什么。认为phone book这个指数有多有效？对每个姓都有不同的书会更好吗？

这不会给你任何明智的表现。保留单个表格，但一定要在用户标识上索引，并且您将能够快速获取数据。然而，如果将表格拆分，那么获得跨越多个用户的任何信息变得不可能/非常困难，例如搜索某个特定窗口小部件的所有用户，特定类型的所有窗口小部件的计数等等。您需要每个查询动态构建。

如果删除行很慢，请查看该行。我们一次谈论10,1000,100000多少行？这张桌子上的聚簇索引是什么？你可以使用“软删除”，你有一个状态列，你更新为“D”标记行被删除。你可以在以后删除行，数据库活动较少。是删除缓慢，因为它被其他活动阻止。在分解表格之前查看这些内容。

来源

2011-08-19 12:52:59

动态地创建数据库表作为分区的手段是否合理？

号（笑）

来源

2011-08-19 11:48:25

所以你从他的整个文本中拿出一个问题，并回答一个单词的答案？这对他来说很难学习... – Konerak

他的整个文本*是*这个问题，这是一个错误的问题。 “动态创建表格”不是问题，它是一个解决方案。显然，OP的问题是DELETE性能很差，可能是在多租户数据库中。 –

不，这将是一个坏主意。然而，一些DBMS（例如Oracle）允许单个表在列的值上进行分区，这将实现目标，而不会在运行时创建新表。话虽如此，分区表不是“规范”：它通常只在非常大的数据库中完成。

来源

2011-08-19 11:48:51

使用userID上的索引应该可以获得接近相同的性能。

在我看来，在运行时更改数据库模式是不好的做法。考虑，例如，安全问题...

来源

2011-08-19 11:49:51

动态创建表作为分区的一种方式：好还是坏做法？

回答

相关问题