編集：私はこれを間違ったと言います。外部キーの制約として外部キーを読んでください。私はアドレステーブルなどにクライアントIDが必要であることを理解しています。は必要なアドレステーブルの外部キーの関係です
私はクライアントテーブルを持っています。 id： pref_name | full_name |ビジネス名|等。 。 。
私はクライアントが複数の場所/アドレスを持つことができるので、私はアドレステーブルを持っていることに気付きました。 id： client_id |名前|アドレス1 | | sub_area_id | area_id | province_id | country_id |郵便番号|等。 。 。
その後、私はクライアントが複数の国から来ることができることを認識したので、次のように追加しました。 country table id |国|コード（ISO-2A）
省テーブル id |名前| country_id
エリアテーブル id |名前| province_id
サブエリアテーブル id |名前| area_id
だから今私はsub_area_id | area_id | province_id |アドレステーブルのcountry_id。
sub_area_idから、私は残りの部分を結合クエリで得ることができますが、必ずしもサブエリアIDがあるとは限りません。常にエリアIDになります。私は必要があると思うsub_area_id | area_idを削除できますが、province_id | country_idからアドレス表
私は確信していないことは、私は国、地域、面積、sub_areaテーブルのための外部キーが必要ですか？
国が削除されていると、他のテーブルのすべての関連データを削除する必要がありますが、国が決して削除されないことは間違いありません。州、地域、sub_areasと同じです。外部キーを実装するのは時間の無駄でしょうか？
また、クライアントは無効になっている可能性があります（履歴データに影響するため、削除されません）。外部キーもクライアントアドレスを無効にすることができますか、無効にする必要はありませんか？再度、クライアントが後で再開できるので、おそらくそれを削除するのが最善ではないでしょう。
私の構造の改善のための提案はありますか？ TIA
FK宣言は、どこか別の場所に表示する必要があります。だから、他の人が暗示しない限り、あなたができるすべてのFKを宣言するか、サイクルが発生し、DBMSはサイクルを処理できません。ただし、管理が完了していないときに制約が苦情を受けても、別のテーブルから取得できる情報をテーブルに保持する必要があります。再削除すると、「ソフト削除」と「履歴データ」が表示されます。この古典的なDBのケースは、物事がどのように変化したかにかかわらず、塗りつぶされたままに保たれた塗りつぶされた注文です。 PS名が変わります。国などが来て行きます。 – philipxy
@philipxy - ありがとう。私は前にsoft deleteという言葉を聞いていなかった。私はSOに関するいくつかの良い情報を見つけ出し、後で必要とされるかもしれないどこのデータも削除できるように実装します。 – Cambo