有一个小系统,会有用户注册,计划当有一个用户注册就在数据库中建立一个属于这个用户的表,这个系统的用户数不能确定,有可能只有100个,也有可能会达到10000个,如果这个系统有10000个用户了,那么就得建立10000个表,不知道这样对数据库的性能有没有什么负面影响。也不知道一个数据库有10000个表是不是合理,请教各位大虾!

解决方案 »

  1.   

    这个很难说,从技术上没什么影响。但主要是看你逻辑上为何这样处理?为什么要每个用户单独建一个表,不能把这些合成一张表吗?
      

  2.   

    这个很难说,从技术上没什么影响。但主要是看你逻辑上为何这样处理?为什么要每个用户单独建一个表,不能把这些合成一张表吗?
      

  3.   

    是为了数据库设计以及程序设计的简洁才提出这么个想法的,当然可以都合成一张表,但是这样的话很多用户的数据都放在这张表上了,所有用户都对这一张表进行操作,怕引起性能低下。所以想到了为每一个用户单独建立表。现在的问题就是当用户数量很大的时候,比如说10000,那么数据库中将会存在10000张表,这样不知道是不是更加得不偿失,性能会更低。
      

  4.   

    要看你的主要操作是什么了?如果每个用户只查自己的,更新自己的,不需要联合查询或偶尔联合查询,则就用这个1000表的方案好了。
      

  5.   

    不合理 !连第一范式都不符合!不会建立这么大的表!!
    就算用户插入修改信息!但是不是主键 我们可以通过建立用户编号为主键的手段将其变成一条数据你可以观察当当等购物网站,信息随便你改动很明显  我们没改主键  
    而且每次变动都会被记录 你可以看到你过去的信息记录即便你现在修改了 就是说,这样的效率很低 冗余度大 出现插入异常 删除异常 修改异常 维护起来很困难! 查找更加不用说 你知道你要查找那种表吗?
    光就表的命名就让系统蹦了!假设用户信息有用还要重新修改所有关于其的数据
    业务逻辑有改动,更加不用说了根本没有拓展性!
    没有利用好关系数据库的特性!
    第一范式(唯一标识)都不符合!所以不能这样考虑!希望我的答案你对你有所帮助!
      

  6.   

    晕 7楼说的好严重,不过很感谢!我还在思考中 ...
      

  7.   


    不能说是表只能说是记录!这样建表的话,连名字都会整死人记录就不同!
      

  8.   

    这样的系统很难维护,三思哈,呵呵