请问这两种数据库设计方案哪种更好？

显示全部楼层 · 2006-4-17 13:46:34

有两种关系，其关系类似与部门与员工的关系（实际不是，这样说好说明）。部门中的种类有限，一般不会超过20个。但每一个部门对应的员工很多，其员工信息最大都有30M。
部门设计成一张表。
但员工信息是设计成一张表？
还是对每一个部门的员工建一张表（部门中的种类也经常变）？
不考虑将员工设计成分区表。
我想，如果员工只有一张表，这个数据量就可能很大，这会不会有问题，而且查询等操作会不会很慢。
如果设计成多张表，就必须在程序种动态的创建于删除表（虽然表结构一样）。
请大家出个主意！

千问 · 2006-4-17 13:46:34

部门的种类变化时，员工的信息要全部DELETE还是只变动相关的一些信息？
如果要全部DELETE我建议多张表，若没有我觉得不需要多张表，只要建好用好索引速度不会慢的。

千问 · 2006-4-17 13:46:34

对于员工的检索是否有不按照部门来做的，如果有，建议建在一个表，一个表30M不算大，如果有流文件可以再单建一个存储表。

千问 · 2006-4-17 13:46:34

部门变了。其对应的员工信息倒不需要全部删除。
但员工必须以部门号和员工号两个字段为主键，不同部门的员工号可相同。但我担心表太大了会不会对数据库有影响？

千问 · 2006-4-17 13:46:34

每次操作前提是在一个部门下，然后对其中的员工信息进行添加、删除、修改。

千问 · 2006-4-17 13:46:34

一般来讲，具有相同属性的对象要方到同一个表中，但是要根据应用的需要来看，如果分多个表，假设有某个修改是针对所有员工的，你就要修改20个表，还不如和在一起，或者分区；如果你的应用中，都是仅仅对某个部门的操作，那可以考虑分多个表。
如果你员工的信息中有些照片或语音之类的对象，因为它们很少会更新，你可以考虑为这些单建一个表，使用不同的存储参数。

千问 · 2006-4-17 13:46:34

我觉得员工用一个表好，这样一来在程序设计时要方便很多！

千问 · 2006-4-17 13:46:34

顶多6,700M数据
建立个联合索引很快的还对编程方便
分区+并行