A、B假如数据量不大,那么用分开
假如数据量很大,那么两表中都存放 id(c),用触发器,来维护唯一性

解决方案 »

  1.   

    我的建议是:设计尽量符合数据库范式,保证数据的完整性和唯一性。
    速度慢可以通过增加硬件设置,提高内存容量来解决,而数据出现不一致,导致程序出现问题,只能靠人去维护,而人的维护成本可能比增加硬件的成本还要高。
    当然具体问题也要具体分析,如果有些问题是增加硬件设置也收效不大,或是速度慢的问题很突出,也可以打破范式,通过冗余字段来提高效率。不过一定要有这个概念,违反范式是要付出代价,如果收益不是很大,就不要使用。
    你说的这个问题,只有两到三个表的联结,数据库本身就已经对联结做个优化,速度不会比查单个表慢多少,为了获得稍微快一点的速度而去破坏范式,不值得。如果你觉得表联结查询不方便,可以定义视图,并建立索引(sqlserver2000支持)。数据库设计的一般步骤:先严格按照数据库第三以上范式来定义表,然后再根据每个表的记录可能达到的数量,来优化表结构,增加冗余字段,但这种操作每做一次,都要有大量的依据和对数据量的准确估计作为前提。
      

  2.   

    to:bluepower2008(蓝色力量)
    真是谢谢你的多次帮助,我的几个问题都是你答的,太谢谢了
    我再看看其他的人的意见把
      

  3.   

    部分同意以上名位的观点,在设计数据库时考虑数据的完整性和唯一性的确很重要。
    凡事没有绝对的。我们不能死守着理论。实际上,若你的表比如b表比较大的话
    一百万条以上,或者你的服务器性能一般,你可以考虑将c字段并入表b,
    若表b一般情况下顶多几万或者十几万,确实没有必要牺牲完整性和唯一性,反正,
    一切取决于实际情况。不能仅仅看理论。
      

  4.   

    to: baresi(定海神针)
    真的回答了你很多问题吗?我倒没注意,问题感兴趣我就回答。
    不过如果真问答了你不少问题的话,那我们还是有缘!!
      

  5.   

    可以建立“约束”来保证A和B里面c的一致性。
      

  6.   

    同意 smartdonkey(聪明的毛驴)  的观点。平衡论永远正确!
      

  7.   

    尽量符合范式,但是有时也可以适当借助冗余字段。我编写一个考勤系统时,碰到这样的情况,有两个表:
    Emp存放雇员基本信息;
    OTRECORD存放加班时间。
    OTRECORD的字段有:
    rid, employeeid, otdate, otduration, ottype
    其中的ottype和另一个表有关联。在汇总时要计算每个人在一定的日期段内的不同加班类型和加班时间。发现用JOIN啊什么的做都很累,最后我在EMPLOYEE中增加了三个冗余字段,OT1,OT2,OT3用来表示三中不同类型的加班时间。程序一下就简单了。当然,这会给程序带来维护的问题:例如要增加一个加班类型就有问题。需要在实践中平衡。
      

  8.   

    to TR@SOE():(你的星真多)
    你说的这种情况,如果不是因为连接导致查询速度慢,而是写sql语句麻烦,我建议你使用视图,比加冗余字段来解决可能更好一些。