This topic has been archived. It cannot be replied.
-
工作学习 / 专业技术讨论 / 数据库的Architects大虾们请进：
-23456789(大白呼);
2006-11-7
{786}
(#3307459@0)
-
一个数据库虾米的看法：我选方法2.你觉得有什么顾虑吗？
-newkid(newkid);
2006-11-7
(#3307497@0)
-
Choose 2 .Maybe It is a "大表" But it is not a "长长大表".just a regular table. Example, Column: Client_ID, [Client_name],Product_ID,[Product_name],[REQ_Quantity]. Then insert multi rows into the table for each client.
Key word: use rows, do not use columns.
-hard20(hard20);
2006-11-7
{201}
(#3307616@0)
-
怎么不是长长的？行数等于产品总数Ｘ客户总数。
-23456789(大白呼);
2006-11-7
(#3307687@0)
-
那也比“宽宽的”(OPTION 3)好。总行数是什么数量级的？
-newkid(newkid);
2006-11-7
(#3307739@0)
-
估计在一个米粒左右
-23456789(大白呼);
2006-11-7
(#3307765@0)
-
Why do you need all "0" values in your table. Even when a client does not want any products.
-hard20(hard20);
2006-11-7
(#3307926@0)
-
一个米粒 rows ? If you are using Oracle or SQL 2005, partition your table if you have any performance issues.
-hard20(hard20);
2006-11-7
(#3307941@0)
-
no need to partition the table for 1M rows, not a problem at all
-newkid(newkid);
2006-11-7
(#3307950@0)
-
2是最正道的选择，要quick&dirty的话1也可以，3是最恶心的
-pasu(InTheSky);
2006-11-7
(#3307672@0)
-
你在创建Fact 表，选方法2， 还可以建MQT or MV 在Fact 表上。网上应该找得到现成的DW设计吧。
-886xyz(cqcq);
2006-11-7
(#3307691@0)
-
MQT or MV 是啥玩艺？
-23456789(大白呼);
2006-11-7
(#3307703@0)
-
Materialized Query Table / Materialized ViewSchema could be like:
Customer: cid, ...
CustProf: cpid, lid, (vid or date or other kind of version control)
Lineitem: lid, pid, p#
Product: pid, ...
Customer 1---m CustProf 1---m Lineitem m---1 Product
-886xyz(cqcq);
2006-11-7
{212}
(#3307721@0)
-
I do not think this is a design for DW env, It should be a OLTP application
-hard20(hard20);
2006-11-7
(#3307916@0)
-
it's a tipical many to many relationship. add one more table to store the profile. Keys related to 产品名录表 and 客户表
-benbendan(相忘于江湖);
2006-11-7
(#3307693@0)
-
if i understand you, the profile table is just a convenient tool for generating the order info.
-digitworm(digitworm);
2006-11-7
(#3307824@0)
-
需求不明确，问题:1. 是不是客户每次订购的产品种类、数量相似，但不相同？
2. 订购单需要记录详细的订货情况,而不是一个总金额？
3. 你需要一个简便的方法输入订单？
-yehongwei(天拖南);
2006-11-7
{140}
(#3307894@0)
-
自动订货系统设计。
-23456789(大白呼);
2006-11-7
{740}
(#3307994@0)
-
俺理解你的业务流程是这样的...1. 先把货运到客户处，货还算你们公司的
2. 客户不停地用
3. 你们公司定期上门送货并清点货物，上次存货减去这次存货（加上新送的货之前），就是客户消耗的数量
4. 回来做订单，生成发票
上面猜的对不对？
这应该算作Consigned Inventory
先别谈怎么设计，把业务流程，系统要实现其中那部分功能，再考虑设计
-yehongwei(天拖南);
2006-11-7
{296}
(#3308038@0)
-
考虑啥设计？没有什么花头精，大家一直推荐了２。我就来试一试２。
-23456789(大白呼);
2006-11-7
(#3308053@0)
-
天拖南说的没错，如果你不理解客户的业务流程，很难想象你的选择是正确的。
-ice(Déjà vu);
2006-11-7
(#3308074@0)
-
听起来很复杂，只怕几个表都搞不定。
-canadiantire(轮胎-pax et lux);
2006-11-7
(#3308097@0)
-
别光考虑那些跟需求有关的字段，还要考虑跟开发和维护相关的字段，比如flag，timestamp什么的.
-hard20(hard20);
2006-11-7
(#3308197@0)
-
除了2，其他都很恶心。在客户和产品之间弄个多对多的表好像是唯一选择。很常见的case难道还能弄出什么新的恶心design来？
-maplew2008(call me at 911);
2006-11-7
(#3307936@0)
-
选2）。1，3都不可行，随着客户的增加减少会产生schema change, 根本违反数据库设计理论
-ubs(ubs);
2006-11-7
(#3308187@0)
-
none of options will work
-kpax(kosmo);
2006-11-7
(#3308579@0)
-
就这么一句话就给判死刑啦?
-23456789(大白呼);
2006-11-8
(#3308906@0)
-
1,3根本不能考虑.2是很自然的,但是要看具体的业务需求.我觉得有可能可以按需求的近似程度把客户划分成不同的group,每个group中的客户共用一个profile;另外需求数量为0的不记进去,这样profile表的行数可以小很多
-heeltoe(不過三);
2006-11-8
(#3308935@0)