数据模型草案/报价/订单/发票

Question

我目前正在做一个小项目，在这个项目中，我需要对以下场景建模：

场景

1. 客户来电，他想要一辆新车的报价。
2. 销售代表。注册客户information.
3. Sales代表。在系统中创建一个报价，并将一个项目添加到报价(汽车)中。
4. 销售代表。将报价发送给email.
5. Customer上的客户，接受报价，现在报价不再是报价，而是订单。
6. 销售代表。检查订单，一切正常，他开发票。现在订单不再是订单，而是发票。

Thoughts

我需要一些帮助，找到理想的方式建模，但我有一些想法。

我在想，两个草稿/报价/发票基本上都是一个order.

• Draft/quote/invoice，需要单独的唯一数字(Id)，所以在这里，我想为所有这些单独的表。

模型

这是我的数据模型v.1.0，请让我知道你的想法。

​

关注

然而，我对这一模式感到关切：

1. Draft/quote/invoice在定单线上可能有不同的商品和价格。在这种模式中，所有的汇票/报价/发票都与同一订单和订单线相连接，因此不可能有单独的报价行/草稿线/发票线。也许我会为此做新的表，但基本上相同的信息将存储在多个表中，这不是很好的either.
2. Sometimes两个或多个报价成为发票，这个模型将如何处理这个问题？

如果你对如何更好地塑造这个模型有任何建议，请告诉我！

编辑:数据模型v.1.4

​

Answer 1

看起来你已经把这些东西中的每一件--报价，订单，汇票，发票--都建模成了与所有其他东西结构相同的模型。如果是这样的话，那么您可以将所有类似的属性“推”到一个表中。

create table statement (
    stmt_id integer primary key,
    stmt_type char(1) not null check (stmt_type in ('d', 'q', 'o', 'i')),
    stmt_date date not null default current_date,
    customer_id integer not null  -- references customer (customer_id)
);

create table statement_line_items (
    stmt_id integer not null references statement (stmt_id),
    line_item_number integer not null,
    -- other columns for line items
    primary key (stmt_id, line_item_number)
);

我认为这将适用于您所描述的模型，但我认为从长远来看，将这些模型建模为一个超级/子类型会更好。所有子类型共有的列都被“向上”推到超级类型中；每个子类型都有一个单独的表，用于该子类型特有的属性。

This SO question及其公认的答案(和注释)说明了博客评论的超级类型/子类型设计。Another question与个人和组织有关。Yet another与人员配置和电话号码有关。

稍后是。。。

这还没完成，但我没时间了。我知道它不包括行项。可能漏掉了别的东西。

-- "Supertype". Comments appear above the column they apply to.
create table statement (
  -- Autoincrement or serial is ok here.
  stmt_id integer primary key,    
  stmt_type char(1) unique check (stmt_type in ('d','q','o','i')),
  -- Guarantees that only the order_st table can reference rows having
  -- stmt_type = 'o', only the invoice_st table can reference rows having
  -- stmt_type = 'i', etc.
  unique (stmt_id, stmt_type),
  stmt_date date not null default current_date,
  cust_id integer not null -- references customers (cust_id)
);

-- order "subtype"
create table order_st (
  stmt_id integer primary key,
  stmt_type char(1) not null default 'o' check (stmt_type = 'o'),
  -- Guarantees that this row references a row having stmt_type = 'o'
  -- in the table "statement".
  unique (stmt_id, stmt_type),
  -- Don't cascade deletes. Don't even allow deletes. Every order given
  -- an order number must be maintained for accountability, if not for
  -- accounting. 
  foreign key (stmt_id, stmt_type) references statement (stmt_id, stmt_type) 
    on delete restrict,
  -- Autoincrement or serial is *not* ok here, because they can have gaps. 
  -- Database must account for each order number.
  order_num integer not null,  
  is_canceled boolean not null 
    default FALSE
);

-- Write triggers, rules, whatever to make this view updatable.
-- You build one view per subtype, joining the supertype and the subtype.
-- Application code uses the updatable views, not the base tables.    
create view orders as 
select t1.stmt_id, t1.stmt_type, t1.stmt_date, t1.cust_id,
       t2.order_num, t2.is_canceled
from statement t1
inner join order_st t2 on (t1.stmt_id = t2.stmt_id);

Answer 2

应该有一个表“商”，类似于“命令行”。类似地，您应该有一个‘发票线’表。所有这些表都应该有一个“价格”字段(名义上将是该部分的默认价格)和一个“折扣”字段。您还可以在“报价”、“订单”和“发票”表中添加“折扣”字段，以处理现金折扣或特殊优惠等问题。尽管您写了什么，但是有单独的表是的，因为报价中的数量和价格可能与客户的实际订单不匹配，而且也可能与您实际提供的数量不同。

我不确定“草稿”表是什么--您可能会将“草稿”和“发票”表合并，因为它们包含相同的信息，其中一个字段包含发票的状态--草稿或最后一个。将您的发票数据与订单数据分离是很重要的，因为您可能会根据您的收入(发票)纳税。

“引号”、“订单”和“发票”都应该有一个字段(外键)，该字段保存销售代表的值；该字段指向不存在的“SalesRep”表。您还可以在“customers”表中添加“salesrep”字段，该字段指向客户的默认代表。这个值将被复制到“引号”表中，尽管如果默认的另一个代表给出了引号，它可能会被更改。类似地，当从报价发出订单和从订单发出发票时，应复制此字段。

我可能会添加更多，但这取决于您想要创建的系统有多复杂和详细。你可能需要添加某种形式的“材料清单”，如果汽车是根据他们的选择配置，并相应定价。

Answer 3

向line_items添加一个新列(例如:状态为smallint)

当一个quote_line变成order_line，然后从0到3到1之间选择set位。

但是，当qty发生变化时，添加一个新的qte行，并保持最后一行不变。

卡德。