リレーションについて

質問

伝票データを各テーブル(ヘッダと明細)に分けたい格納したいと考えています。
※ヘッダ情報と明細にヘッダNoというフィールドを作成してこの値で紐付けるようにしています。

そこで皆さんに質問があります。
ヘッダ情報を削除した際に紐づいている明細データも一緒に削除され、明細のみ削除する際はヘッダ情報は削除されずに明細のみが削除されるような仕組みにするにはどうしたらいいでしょうか。
またこういう機能ってういか、仕組みの事を何て言うんでしょうか。
※確かテーブルを作成する際に何か記述したらできたような記憶がするんですが・・・
　間違っていたらすみません。

説明が下手ですみませんが理解していただけましたでしょうか。
申し訳ありませんがアドバイス宜しくお願いします。

回答No.2

nda23 · ベストアンサー

もともと親子関係においては
(1)子は親の値しか使用できない。
(2)親は子が存在する間は削除できない。
(3)親は子が存在する間は変更できない。
というルールなのです。
だから、ON DELETE とかON UPDATE は
オマケみたいなもので、本来は無いと
考えるべきです。
DELETEはキー整合をとりますが、
TRUNCATEは何も考えずバッサリ
なので、処理速度は断然有利です。
その代わりON DELETEが利かず、
不整合が生じる可能性があるため
外部キー参照のあるテーブルでは使用
できません。
外部キー参照は物理的に整合性を保つ
ためには便利ですし、親子結合で行う
クエリも高速です。但し、データの追加や
削除で、リレーションシップの更新を伴う
ため、こういう関係を持たないテーブルの
追加/更新より時間がかかるという欠点も
あります。
かつて、CPUの性能が悪く、DBが遅い
時代にはリレーションの設計は大事な
要素でした。しかし、何時の頃からか
リレーションは廃れてしまい、今は取り
入れない方が普通になりました。
レコード数が大量で親子関係の参照機会が
多く、データの追加/変更/削除の頻度が
低い場合は外部キー参照は有効です。
それ以外では物理的な関係は持たない方が
よいでしょう。

お礼

返答が遅くなってすみません。

大変、勉強になりました。
リレーションを貼らない方向でやりたいと思います。
本当にありがとうございました。

回答No.3

masa--oka

アプリケーションの詳細がわからないので何とも言えないのですが、
販売管理等のアプリでは単純にデータを削除しないほうがいいです。
削除すると経緯が全く分からなくなるので、
マイナスの売上をたてる、もしくは、削除フラグを立てるといった処理の方が賢明です。

お礼

返答が遅くなってすみません。

なるほど。
削除フラグを追加して対応したいと思います。
本当にありがとうございました。

回答No.1

nda23

「外部キー制約」という方法を使います。
ヘッダの定義
CREATE TABLE HEADER (
HEADER_NO VARCHAR(4) PRIMARY KEY,
～);
明細の定義
CREATE TABLE DETAIL (
HEADER_NO VARCHAR(4)
REFERENCES HEADER(HEADER_NO)
ON DELETE CASCADE
～);
http://www.postgresql.jp/document/9.1/html/ddl-constraints.html#DDL-CONSTRAINTS-FK

補足

返事がおそくなってすみません。
nda23さんのアドバイス通りテーブルを作成して、各テーブル(HEADER、DETAIL)にレコードを追加、そしてHEADERテーブルのレコードを削除したらDETAILのレコードも一緒に削除する事ができました。
ありがとうございました。

外部キーを指定したテーブルに「TRUNCATE TABLE」を実行したらエラーが出力されました。
調べたら外部キーを指定したテーブルには「TRUNCATE TABLE」が使えない事を知りました。
・cannot truncate a table referenced in a foreign key constraint

もう少し私にお付き合いしていただけませんでしょうか。
外部キーを指定する方法と各テーブル(HEADER、DETAIL)に対してDELETEを実行する方法ではどちらが適切なのでしょうか。
私の勉強不足で申し訳ありませんが再度、アドバイスいただけませんでしょうか。
宜しくお願いします。