CRM高手请进

月亮

刚开始接触CRM，觉得超级复杂而繁琐，所以有两个简单的问题想请教：
1。要全面了解CRM数据库中各个table的关系，有什么好办法没有？我现在用的是最笨的方法，就是一个个看，一点点理
2。我发现很多数据在多个table中重复储存（比如一个叫ID的column在一半以上的表中都作为pk的一部分），或者，有些表除了pk之外，有80%以上的colum值为null（既基本上都是默认值），这是CRM本身的特点还是设计DB的时候有欠考虑的地方？

请CRM高手指点，有啥经验之谈也欢迎说说。

daisyhey

这个跟CRM没管，主要是数据库方面的
1，不知道你用什么db，但在database下都有一个diagram的文件夹，你可以在里面新建ER图，选择你要查看的table,view加进去，系统会根据主外键的关系自动生成ER图，显示表的字段和表间的关系，当然这个关系是dba设计table的时候定义好的，如果没有，你也可以自己画线。。 这样你对应的看，就会明白数据库的结构了

2，那么这个ID就是表的外键，指向对应的字典表。null列多也没有关系，只要不是主键或者关键的字段，如果要求非空可以在gui上作check, null反而在编程或者测试的时候省事儿

瞎说说啊

ccj5124

1。用visio好像可以生成关系图。
2。id重复是很正常的啊。想想看，像客户ID，基本在每个表里都会出现啊（地址表，日志表，客户资料表，客户交易表...）。其他信息应该不重复。null也很正常啊，现在硬盘这么便宜，不用关心这个吧。

月亮

因为有一个ID用在几百个表上，所以没法用diagram打开，如果选几个表打开还是理不清关系。
我之前没有见过这样设计db的，因此好奇是不是crm的特征。

daisyhey

欧，对了，可能你说的ID是每一个表的主键，都叫ID，但不表示一个意思，比如orderID,productID,comstomerID,有的dba爱用identity自增的数列来作记录唯一的标识，unique index，这样做比用几个字段组合来标示主键简单好操作，但逻辑上表里还是有别的字段用来做primary key。比如

ID, order_no, order_line_no, Product_no

ID 作unique index，但业务上还是order_no, order_line_no作primary key

月亮

原帖由 ccj5124 于 2006-10-4 21:25 发表
1。用visio好像可以生成关系图。
2。id重复是很正常的啊。想想看，像客户ID，基本在每个表里都会出现啊（地址表，日志表，客户资料表，客户交易表...）。其他信息应该不重复。null也很正常啊，现在硬盘这么便宜， ...

我用ID是打个比方，实际上是一个没有任何意义的sequence number，可能是我多虑了。

daisyhey

原帖由 月亮 于 2006-10-4 21:29 发表
因为有一个ID用在几百个表上，所以没法用diagram打开，如果选几个表打开还是理不清关系。
我之前没有见过这样设计db的，因此好奇是不是crm的特征。

这个跟设计数据库的人有关，有的作GUI的人方便了，作报表的人却能累死

daisyhey

原帖由 月亮 于 2006-10-4 21:31 发表


我用ID是打个比方，实际上是一个没有任何意义的sequence number，可能是我多虑了。

这个就是为了编程方便，根据一个字段就能抓到数据

dust2k

原帖由 daisyhey 于 2006-10-4 21:33 发表


这个就是为了编程方便，根据一个字段就能抓到数据

主要是为了Report的性能。。数据的亢余是一种折衷，有时候必须为了某些Query的性能牺牲normalization

widelink

原帖由 daisyhey 于 2006-10-4 21:33 发表


这个就是为了编程方便，根据一个字段就能抓到数据

这说明 你们公司的db是编程写gui那些人做的， 人家做报表的说不上话，要不就是没有:si56

bulaohu

one thing here...null value is not redundancy, conceptually.

月亮

原帖由 bulaohu 于 2006-10-4 21:46 发表
one thing here...null value is not redundancy, conceptually.

现在的情况是比如一个表有100个column,80多个都是null,当运行一个query的时候，即使只要1，2个column的数据也必须把整条数据所在的page读入buffer，这样不是大大增加了disk I/O降低了performance么？

月亮

原帖由 daisyhey 于 2006-10-4 21:32 发表



这个跟设计数据库的人有关，有的作GUI的人方便了，作报表的人却能累死

没错，run一个report要半个多小时，做报表的跑来抱怨，可是我也无能为力啊，郁闷。。。

dashaguaus

我想你看到时base table. 再base table 之上，还应该有一些view 或者是snapshot,看这些view 或者是snapshot或许更容易理解一些。 我在工作中接触一些CRM, 的确好多field is null or constant value. I guess that is because the ard disk is now very cheap and query spead is more important than data   redantency.

dashaguaus

原帖由 月亮 于 2006-10-4 21:57 发表


现在的情况是比如一个表有100个column,80多个都是null,当运行一个query的时候，即使只要1，2个column的数据也必须把整条数据所在的page读入buffer，这样不是大大增加了disk I/O降低了performance么？

not necessary, if you have index on the two fields

bulaohu

原帖由 月亮 于 2006-10-4 21:57 发表


现在的情况是比如一个表有100个column,80多个都是null,当运行一个query的时候，即使只要1，2个column的数据也必须把整条数据所在的page读入buffer，这样不是大大增加了disk I/O降低了performance么？

That's why I say "conceptually"...but still,

1. null data is as valuable as a number like 129433.224338, from a technical point of view;

2. Actual storage on HDD is probably compressed - a 8k page with 80% null values may end up only taking 2k HDD space. This actually speeds up I/O.

a711012

什么CRM产品?