fiz*_*ban 3 sql database database-design
应用程序动态创建数据库表作为分区方法是否合理？
例如,假设我有一个大表"小部件",其中"userID"列标识每行的所有者.如果此表倾向于变得非常大,那么让应用程序为每个新用户创建一个名为"widgets_ {username}"的新表是否有意义？假设应用程序将只需要一次查询属于单个用户的小部件(即,不需要尝试将这些用户小部件表中的任何一个加入到一起).
这样做可以将一个大表分解为更容易管理的块,但这似乎不是一个优雅的解决方案.在我看来,应该在编写应用程序时定义数据库模式,并且任何运行时数据都存储为行,而不是作为附加表存储.
作为一个更普遍的问题,在运行时修改数据库模式是否正常？
编辑:这个问题大多是假设的; 我有一种很好的感觉,在运行时创建表是没有意义的.话虽这么说,我们的应用程序中有一个包含数百万行的表.SELECT执行得很好,但是删除特定用户拥有的所有行可能需要一段时间.基本上我正在寻找一些可靠的推理为什么动态创建每个用户的表对我问的时候没有意义.
不不不!!现在重复一遍,I will not do this because it will create many headaches and problems in the future! 数据库可以处理大量信息.他们使用索引快速找到你所追求的东西.想想phone book 指数有多有效？为每个姓氏准备一本不同的书会更好吗？
这不会给你任何明智的表现.保留一个表,但一定要在UserID上编制索引,并且您将能够快速获取数据.然而,如果你将表分开,那么获得跨越多个用户的任何信息变得不可能/真的很难,例如搜索特定小部件的所有用户,特定类型的所有小部件的数量等等.你需要拥有每个查询动态构建.
如果删除行很慢,请查看.我们一次谈论的行数是10,1000,100000？这张桌子上的聚集索引是什么？您是否可以使用"软删除",其中您有一个状态列,您将其更新为"D"以将该行标记为已删除.您可以在以后删除行,数据库活动较少.删除速度很慢,因为它被其他活动阻止.在你分手之前先看看那些.