×

Loading...
Ad by
  • 推荐 OXIO 加拿大高速网络,最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务
Ad by
  • 推荐 OXIO 加拿大高速网络,最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务

数据库的Architects大虾们请进:

一个公司的产品有很多。客户也很多。这样的数据库当然就包括了

1。产品名录表(带有条码)
2。客户表。
3。订购单表(做Invoice用)

我的疑问是,不同的客户有不同不同的Profile,每种产品的需求量各客户之间是不同的。这个Profile怎样设计比较科学?

Profile应该是产品名录一样的表,但是附有各种产品需求数量。我所能想出来的是

方法1。每一个客户有一个产品名录表。麻烦的是这样在做定单的时候就要去调对应的Profile表。而且产品更新时需要更新所有的Profile表。

方法2是一个长长大表,包括了所有的Profiles,加一列客户Key区分。同一产品会重复多次,每个客户一次(因为每个客户需求量不同)。

方法3。将产品名录做成一个Look up table,除了产品本身介绍外,有无数多的列,每一列是一个客户。缺点是没增加一个客户就要去新开一列。可是数据库的最多列数可能是有限的。

还有什么更科学的方法?帮我东东脑筋吧?
Report

Replies, comments and Discussions:

  • 工作学习 / 专业技术讨论 / 数据库的Architects大虾们请进:
    一个公司的产品有很多。客户也很多。这样的数据库当然就包括了

    1。产品名录表(带有条码)
    2。客户表。
    3。订购单表(做Invoice用)

    我的疑问是,不同的客户有不同不同的Profile,每种产品的需求量各客户之间是不同的。这个Profile怎样设计比较科学?

    Profile应该是产品名录一样的表,但是附有各种产品需求数量。我所能想出来的是

    方法1。每一个客户有一个产品名录表。麻烦的是这样在做定单的时候就要去调对应的Profile表。而且产品更新时需要更新所有的Profile表。

    方法2是一个长长大表,包括了所有的Profiles,加一列客户Key区分。同一产品会重复多次,每个客户一次(因为每个客户需求量不同)。

    方法3。将产品名录做成一个Look up table,除了产品本身介绍外,有无数多的列,每一列是一个客户。缺点是没增加一个客户就要去新开一列。可是数据库的最多列数可能是有限的。

    还有什么更科学的方法?帮我东东脑筋吧?
    • 一个数据库虾米的看法:我选方法2.你觉得有什么顾虑吗?
      • 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.
        • 怎么不是长长的?行数等于产品总数X客户总数。
          • 那也比“宽宽的”(OPTION 3)好。总行数是什么数量级的?
            • 估计在一个米粒左右
              • Why do you need all "0" values in your table. Even when a client does not want any products.
              • 一个米粒 rows ? If you are using Oracle or SQL 2005, partition your table if you have any performance issues.
                • no need to partition the table for 1M rows, not a problem at all
    • 2是最正道的选择,要quick&dirty的话1也可以,3是最恶心的
    • 你在创建Fact 表,选方法2, 还可以建MQT or MV 在Fact 表上。网上应该找得到现成的DW设计吧。
      • MQT or MV 是啥玩艺?
        • Materialized Query Table / Materialized View
          Schema 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
      • I do not think this is a design for DW env, It should be a OLTP application
    • it's a tipical many to many relationship. add one more table to store the profile. Keys related to 产品名录表 and 客户表
    • if i understand you, the profile table is just a convenient tool for generating the order info.
    • 需求不明确,问题:
      1. 是不是客户每次订购的产品种类、数量相似,但不相同?
      2. 订购单需要记录详细的订货情况,而不是一个总金额?
      3. 你需要一个简便的方法输入订单?
      • 自动订货系统设计。
        1。客户需求有多有少,有的对某种需求多,其他少。所以每个需要不同的服务。
        2。每隔一定周期上门订货服务。只要清点一下库存就行。回来后从Profile中减掉库存,就是某种商品应送货数量。如果某种商品每次都有很多剩余存货,Profile就需要减少,相反,每次点货用光的,或库存很少的,说明应该增加送货量。这些都由附带的统计程序做定期调整。
        3。这个系统不是消极地等待客户来订货,而是主动地去订货。一旦有新产品就自动加入各Profile。这是有点强制订货的味道。但是客户服务做得很好,上门服务,而且送货的时候不付款,下次点货时少了的就是用掉的。用掉了才付款。
        4。Profile表中还有价格。常用产品有竞争产品利润低,独家经营产品,特殊产品利润高。大客户折扣多,小客户折扣少。有些客户有特殊合同,细节涉及到Profile。

        反正是个挺复杂的系统。我认识到,Profile表是非常关键的。
        • 俺理解你的业务流程是这样的...
          1. 先把货运到客户处,货还算你们公司的
          2. 客户不停地用
          3. 你们公司定期上门送货并清点货物,上次存货减去这次存货(加上新送的货之前),就是客户消耗的数量
          4. 回来做订单,生成发票

          上面猜的对不对?
          这应该算作Consigned Inventory

          先别谈怎么设计,把业务流程,系统要实现其中那部分功能,再考虑设计
          • 考虑啥设计?没有什么花头精,大家一直推荐了2。我就来试一试2。
            • 天拖南说的没错,如果你不理解客户的业务流程,很难想象你的选择是正确的。
        • 听起来很复杂,只怕几个表都搞不定。
        • 别光考虑那些跟需求有关的字段,还要考虑跟开发和维护相关的字段,比如flag,timestamp什么的.
    • 除了2,其他都很恶心。在客户和产品之间弄个多对多的表好像是唯一选择。很常见的case难道还能弄出什么新的恶心design来?
    • 选2)。1,3都不可行,随着客户的增加减少会产生schema change, 根本违反数据库设计理论
    • none of options will work
      • 就这么一句话就给判死刑啦?
    • 1,3根本不能考虑.2是很自然的,但是要看具体的业务需求.我觉得有可能可以按需求的近似程度把客户划分成不同的group,每个group中的客户共用一个profile;另外需求数量为0的不记进去,这样profile表的行数可以小很多