×

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

@Calgary

自动订货系统设计。

23456789(大白呼)
１。客户需求有多有少，有的对某种需求多，其他少。所以每个需要不同的服务。
２。每隔一定周期上门订货服务。只要清点一下库存就行。回来后从Profile中减掉库存，就是某种商品应送货数量。如果某种商品每次都有很多剩余存货，Profile就需要减少，相反，每次点货用光的，或库存很少的，说明应该增加送货量。这些都由附带的统计程序做定期调整。
３。这个系统不是消极地等待客户来订货，而是主动地去订货。一旦有新产品就自动加入各Profile。这是有点强制订货的味道。但是客户服务做得很好，上门服务，而且送货的时候不付款，下次点货时少了的就是用掉的。用掉了才付款。
４。Profile表中还有价格。常用产品有竞争产品利润低，独家经营产品，特殊产品利润高。大客户折扣多，小客户折扣少。有些客户有特殊合同，细节涉及到Profile。

反正是个挺复杂的系统。我认识到，Profile表是非常关键的。
(#3307994@0)
Last Updated: 2006-11-7
This post has been archived. It cannot be replied.
Report

Replies, comments and Discussions:

  • 工作学习 / 专业技术讨论 / 数据库的Architects大虾们请进： -23456789(大白呼); 2006-11-7 {786} (#3307459@0)
    一个公司的产品有很多。客户也很多。这样的数据库当然就包括了

    １。产品名录表（带有条码）
    ２。客户表。
    ３。订购单表（做Invoice用）

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

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

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

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

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

    还有什么更科学的方法？帮我东东脑筋吧？
    • 一个数据库虾米的看法：我选方法2.你觉得有什么顾虑吗？ -newkid(newkid); 2006-11-7 (#3307497@0)
      • Choose 2 .Maybe It is a "大表" But it is not a "长长大表". -hard20(hard20); 2006-11-7 {201} (#3307616@0)
        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.
        • 怎么不是长长的？行数等于产品总数Ｘ客户总数。 -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 View -886xyz(cqcq); 2006-11-7 {212} (#3307721@0)
          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 -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)
    • 需求不明确，问题: -yehongwei(天拖南); 2006-11-7 {140} (#3307894@0)
      1. 是不是客户每次订购的产品种类、数量相似，但不相同？
      2. 订购单需要记录详细的订货情况,而不是一个总金额？
      3. 你需要一个简便的方法输入订单？
      • 自动订货系统设计。 -23456789(大白呼); 2006-11-7 {740} (#3307994@0)
        １。客户需求有多有少，有的对某种需求多，其他少。所以每个需要不同的服务。
        ２。每隔一定周期上门订货服务。只要清点一下库存就行。回来后从Profile中减掉库存，就是某种商品应送货数量。如果某种商品每次都有很多剩余存货，Profile就需要减少，相反，每次点货用光的，或库存很少的，说明应该增加送货量。这些都由附带的统计程序做定期调整。
        ３。这个系统不是消极地等待客户来订货，而是主动地去订货。一旦有新产品就自动加入各Profile。这是有点强制订货的味道。但是客户服务做得很好，上门服务，而且送货的时候不付款，下次点货时少了的就是用掉的。用掉了才付款。
        ４。Profile表中还有价格。常用产品有竞争产品利润低，独家经营产品，特殊产品利润高。大客户折扣多，小客户折扣少。有些客户有特殊合同，细节涉及到Profile。

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

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

          先别谈怎么设计，把业务流程，系统要实现其中那部分功能，再考虑设计
          • 考虑啥设计？没有什么花头精，大家一直推荐了２。我就来试一试２。 -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)

More Topics

  • 老程序员第一次用copilot的一点点体会
  • 现在社区游泳池招救生员巡逻，过一会还要不停的点人头，这工作是否很快就被AI代替了，装一个摄像头后面是AI处理系统，这样只招一个等着救人就行了，人头沉下水一定时间立马强光照射，还可以分析水下人的状况来判断是否溺水等
  • 新冠疫苗引发心肌炎? 最新研究这样看
  • 这道几何题有解吗?
  • SAM 2 Demo
    • 枫下论坛主坛 /  工作学习 /  专业技术讨论