数据仓库相关的

——从实际教训中获取的实实在在的经验，可以说非常非常的宝贵。
我现在通过MySQL的show processlist看到时长超过400s的语句都很淡定了。。。
考虑到这是我第一次整数据仓库，还是自我原谅一下~

事实表应该尽可能多的保留字段，即便有些记录的一些字段会是NULL值也没关系（书本上说的好像是事实表内不能有NULL）
因为随着业务、数据量的扩展、添加，无法预测到数据分析的瓶颈会出现在何处，也无法预测是否会添加新的分析需求
——项目中的情况是事实表对应于 access.log 中的记录，在计算【访问次数】的时候需要区别【访问开始时间】，我在做设计的时候没有把【访问开始时间】放进事实表，导致在统计的时候需要进行连接操作。当然还有其他

极致的做法是让事实表的字段尽可能的全用整数
——这个我大概没有时间去重构现有系统了

维度表也应该尽可能的拆分，避免冗余数据导致的数据量添加。这个和第一点说的有点相关
——项目中的情况是有一个【引用页】表，而我未对【引用域名】进行抽取

需要考虑SQL长度问题，上网搜索的时候，网友基本上都会说长度足够，不需要进行特别考虑，结果我拼接的SQL硬生生的超长了
——MySQL的SQL长度，对应于my.conf的配置项max_allowed_packet，默认1M，也就是1024×1024=1048576个字节
——这个问题的原因基本都是对一个List进行查询，我的解决方法是用最简单的递归分解

就这么点吧，其实目的只有一个也很简单：减轻数据库的鸭梨

anyShare分享到：
          

没准儿您会对以下内容感兴趣：