見積書、注文書、下書き、請求書などのすべてのものを、他のすべてのものと構造的に同一のものとしてモデル化したようです。その場合は、同様の属性をすべて 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)
);
あなたが説明したモデルではうまくいくと思いますが、これらをスーパータイプ/サブタイプとしてモデル化することで、長期的にはより良いサービスが提供されると思います. すべてのサブタイプに共通の列は、スーパータイプに「押し上げ」られます。各サブタイプには、そのサブタイプに固有の属性の個別のテーブルがあります。
この SO の質問とその受け入れられた回答 (およびコメント) は、ブログ コメントのスーパータイプ/サブタイプの設計を示しています。別の質問は、個人と組織に関するものです。人員配置と電話番号に関連するさらに別のもの。
後で 。. .
これは完全ではありませんが、時間がありません。広告申込情報が含まれていないことはわかっています。他の何かを見逃したかもしれません。
-- "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);
懸念