员工表中把所属部门的ID和Name都包括了,这显然不符合
数据库范式的要求。
--------------------------------------------
正确. 经理说这是因为数据量大,为提高查询效率所做的反模式应用
------------------------------------------------------
错误,建议深入阅读<<Expert One-On-One>>第一章. 良好的数据库设计是基于数据库的大型系统成功的前提,当然,
在某些条件下,盲目遵从数据库范式也是不对的。 最简单的例子:
进销存业务中的发票明细表,应不应该设置"单价"字段? 从范式的角度来看是不需要的;
但是从用户的使用来看,又是必需的?
数据库范式的要求。
--------------------------------------------
正确. 经理说这是因为数据量大,为提高查询效率所做的反模式应用
------------------------------------------------------
错误,建议深入阅读<<Expert One-On-One>>第一章. 良好的数据库设计是基于数据库的大型系统成功的前提,当然,
在某些条件下,盲目遵从数据库范式也是不对的。 最简单的例子:
进销存业务中的发票明细表,应不应该设置"单价"字段? 从范式的角度来看是不需要的;
但是从用户的使用来看,又是必需的?
对于数据仓库项目或查询量大的项目,这样做是可以的。且有时是必须的!
还是让楼主把基本的架构说说吧? OLTP or OLAP ?
并发用户数 ?
Session数 ?
基础表(像提到过的员工表/部门表)基本架构 ?
活跃表的数据增长频度 ?
不做/做表连接时的具体效率指标 ? 这些都必须考虑,否则, 讨论数据库是否应遵从按范式去设计
没有意义.
To flysnowing(飞雪) :
SQL Server 处理海量数据的效率没法和Oracle/DB2 比
SQL Server 的锁定机制比较烂,经常会导致锁的升级
SQL Server 自身的内存管理机制也不是很科学 选择那种数据库不是看表数目多少来定,需要考虑的因素太多太多.
分析设计不是一个人说了就算,要针对项目需求而定,楼主的系统存在不合理性(个人意见)
从我个人的感觉来说:
员工表,部门表,可能还包括仓库表等等属于小的基础数据表;
而客户,供应商,商品等属于数据量大的基础数据表 业务表与小数据量的表进行表连接,开销不是很大;但是与
大数据量的表进行表间关联时,开销会非常大,因此在这种情况下,
业务表中多一些冗余,存放一些基础表的数据是可行的. 同意Beckhamboo的说法,楼主的系统架构设计可能存在问题.
查询效率可以通过实例视图,索引,分区表等方式来解决。
当然这些对OLTP系统不见得合适。
员工表会达到海量?千万条记录表做一些必要的冗余是可以的,但好像对效率影响不会太大,
因为通常这个表不会构成更大的乘积表,也就是,通常在组成结果集之前完成了条件选择
关键是查询语句要充分优化
所以通常还是尽量满足范式要求
------------------------------------------------------------------
当然了,那是系统保存你当时发言时候的状态,有些论坛还保存签名,是否使用url自动解析,是否解析多样式代码等等你说的这个问题和本文讨论的不是一回事!
数据仓库的数据量够大了吧,可是事实表仍然是遵循模式的,只有维表才是反模式的。
查询效率可以通过实例视图,索引,分区表等方式来解决。
当然这些对OLTP系统不见得合适。-------------------------------------------------------------------------------
事实表的数据一共能多大,几千万条?olap早完蛋了。事实表就是纬度+指标。拿纬度、指标去冗余,会大量增加olap空间,由于现在olap并不是很好,增加空间就降低效率。在dw中冗余数据毫无意义。
在数据仓库的ODS,STAGE中存在大量的冗余数据。在上亿条纪录的情况下,数据仓库的冗余是oltp无法想象的。
在中国现阶段还没有把olap,oltp分开处理
是产生争论的最大问题
单价是必须的,除非你的系统中的物品从不调价
'最简单的例子:
进销存业务中的发票明细表,应不应该设置"单价"字段? 从范式的角度来看是不需要的;'
我个人认为发票明细表中的单价从范式的角度来看是需要的,并不是总价除数量就是单价,因为有四舍五入的问题。
数据量与用多少个报表无关。
to frogdan (阿蛋):
从业务的角度,若要记录员工连续所在部门的信息(即可查以前在那部门),部门的ID和Name同时记录是必须的,公司部门可能重组,原ID号会继续使用,但名称变了。