从理论上来讲，通过ER图等概念模型来设计数据库，并按照一定的范式加以约束，最主要的目的是为了避免数据冗余和数据的不 一致。于是，我们设计的数据库的时候，往往实际中一张表上的东西，在存入数据库时不得不存到几张表中，然后通过编号（主键，外键）互相联系，在需要的时候重新组合成一张完整的表。
我现在的困惑是
1。把表拆分存储后确实最大限度的避免了冗余，节省了存储空间，但是同时，给编程者增加了很多负担，比如要查询一条记录，很可能要去访问好几张表。那对于一个项目，我们究竟在两者间该如何取舍，是为了编程方便保留冗余还是严格按照数据库的理论去做？
2。对于上面所说问题，可能一般我们都会建立视图或者存储过程加以处理。但是，我在用事件查探器中发现，其实这样处理，特别是对于连接了很多表的视图来说，数据处理的量非常大。这样，数据库的负担加重与节省的存储空间相比来说，是否得能偿失？
本人是菜鸟级新手，以前学了很多理论，但很少有机会实践，在真正做东西的时候就觉得很困惑。希望前辈和高手们能给予指点。
我现在的困惑是
1。把表拆分存储后确实最大限度的避免了冗余，节省了存储空间，但是同时，给编程者增加了很多负担，比如要查询一条记录，很可能要去访问好几张表。那对于一个项目，我们究竟在两者间该如何取舍，是为了编程方便保留冗余还是严格按照数据库的理论去做？
2。对于上面所说问题，可能一般我们都会建立视图或者存储过程加以处理。但是，我在用事件查探器中发现，其实这样处理，特别是对于连接了很多表的视图来说，数据处理的量非常大。这样，数据库的负担加重与节省的存储空间相比来说，是否得能偿失？
本人是菜鸟级新手，以前学了很多理论，但很少有机会实践，在真正做东西的时候就觉得很困惑。希望前辈和高手们能给予指点。
如果采用一个大表，这样一条记录的大小是300bt，100万条大约是300M
如果采用两个表，100万条大约是100M你说服务器处理300m的数据和处理100m的数据，哪个负担大 ？2 不利于信息的一致性维护，如果你要修改一个客户的基本信息，如果采用一个表，你要修改多少条有关记录 ？