员工表中增加部门ID就可以，查询的效率你可以理解为没有影响，可以忽略。
公司主营业务：成都网站建设、成都网站设计、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。创新互联是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联推出石林免费做网站回馈大家。
这是关系型数据库中最常见也是最典型的设计方式了。
--创建表sale，字段数量，单价，总额（ps:你应该还需要一个产品id之类的字段吧？）
create table sale(amount number(14) default 0,price number(10,2) default 0,total number(15,2) default 0);
--总额不需要自己计算，创建一个触发器，在insert数据后自动计算
--这个你自己写，触发器里面就是计算数量*单价，然后更新到total字段。
两个方案感觉上都不是太好，建议你还是先细化一下，看看表中数据的增长情况，分为两类，一类是增长较少的，一类是增长频繁的。
对于增长较少的，共同使用一个表空间，这样表空间较少，维护起来比较方便。
对于增长较多的，建议每个表占用一个表空间，然后每天一个分区，而且表空间最好分配到不同的硬盘，好处是系统性能较高，但麻烦的地方是维护较麻烦，需要详细规划。
这个数据的多少和表空间的选择和你的数据量多少是没有太大关系的，需要统计你的数据量的大小。如果数据量很大，像你说的3*100*2000万*1.5k需要估算一下他是有多少G？这样才好设计表空间的分配。从10g开始有表空间支持一个大的数据文件，由多个文件组成肯定没有一个文件好管理，但是如果出问题了一个大数据文件损坏肯定造成的损失很大。这就是易维护性和安全性的取舍。不知道你们磁盘阵列是怎么做的如果没有raid1，数据又很重要的话，也许添加多个数据文件。但是多个数据文件的添加，每个数据文件的大小又受到OS的影响，这个和DB_block_size的大小又有关系，具体算法我不细讲，结论是单个数据文件最多32G。所以这个时候就看你的数据量大小了，你只说量，但是也许有lob字段之类的我无法估算大小，所以这个你自己算一下，如果需要的数据文件过多的话，你想方便维护也是可以使用大数据文件。sql如下：
SQL create bigfile tablespace giapblob ----------------表空间名字
2 datafile 'H:\ypx\pic02.dbf' ----------------数据文件名字路径
3 size 204800M ----------------200G的bigfile
4 autoextend on next 1024M -----------------扩展自动1G
5 maxsize unlimited -----------------不限最大
6 extent management local autoallocate; ----------------自动管理分配区间
其中上述只是从管理方便的角度考虑一个表空间的处理方法，一般单个表空间最大限制是1022个数据文件*4M数据块*DB_BLOCK_SIZE=32TB。如果数据量过大，必须采用多表空间。
另外也要考虑需求中的使用性能，如果表数据量过大，比如你们每天2000万，那有没有历史表数据？这个如果是OLAP还好说，OLTP可能要做分区表等等一系列的性能考虑，情况不同选择不同。
