Chinaunix首页 | 论坛 | 认证专区 | 博客

宋运奎|云开_skysongyunkui.blog.chinaunix.net

云来山更佳, 云去山如画。 山因云晦明, 云共山高下。

  • 博客访问: 1343828
  • 博文数量: 151
  • 博客积分: 7697
  • 博客等级: 少将
  • 技术积分: 3038
  • 用 户 组: 普通用户
  • 注册时间: 2006-03-10 23:04
个人简介

数说青春 http://www.it168.com/redian/yksong/

文章分类
文章存档

2017年(2)

2016年(5)

2015年(1)

2014年(1)

2013年(8)

2012年(5)

2011年(24)

2010年(31)

2009年(1)

2008年(7)

2007年(30)

2006年(36)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

分类: 数据库开发技术

温习记录下
按重要性由大到小列举常见的错误:
10:在事实表中放置用于约束与分组操作的文字型属性。(不可避免时可设计到维度表中。)
9:在维度表中试图为了节省空间而限制使用详细的描述属性。(维度属性越详细越好。)
8:将体系与体系层次分解成多个维度。(重度雪花模型设计者,坏处是会增加事实表与维度表关联的复杂性,影响查询效率,多体系多层级维度是可做单一维度设计的。)
7:忽视跟踪维度变化的需要。(不考虑缓慢变化维的处理,可通过代理键来解决。)
6:通过增加更多的硬件来解决所有的查询性能问题。(优先考虑是否进行了软件层级的性能优化,包括不限于:正确合理的索引、分区分表甚至分库、集合运算、并行计算、分布式计算、数据聚合、业务逻辑拆分等。)
5:使用操作性或者智能关键字将维度表连接到事实表上。(排斥、不使用代理键。)
4:忽视事实表粒度的定义与使用。(糅合各种粒度的数据到事实表中。)
3:基于具体的报表来设计维度模型。(一般为了满足业务需要快速出报表,出现这种情况。但是还是得慢慢沉淀,不断迭代,演进出通用的维度模型。
2:希望用户以规范化的格式查询最底层的原子型数据。(这个活还是留给业务系统来干吧^_^)
1:舍弃在单独的事实表之间保持事实与维度的一致。(尽量达到不同事实表之间维度的高度一致,这是仓库总线结构的基础。)
阅读(1745) | 评论(0) | 转发(2) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册