質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.11%

外部キーにnullを入れない設計をしたい

受付中

回答 6

投稿 編集

  • 評価
  • クリップ 1
  • VIEW 4,708

score 41

前提・実現したいこと

データベースにはmysqlを使い、送金を記録するシステムをつくりたいと考えています。

送金が行われたら記録をするのですが、想定される状況として
「注文なしで行われる送金」(送金のみ)と、
「注文ありで行われる送金」(何かを購入して送金した)と、
「一つの注文から複数の送金」が
あるとします。

この場合、以下のようなデータベース構造になるかと思います。

注文テーブル

ID 取引先ID 担当ユーザーID 合計額

注文詳細

ID 品物ID 品物数量 品物価格

送金記録テーブル

ID 送金額 担当ユーザーID 注文ID

※担当ユーザーテーブルと取引先テーブルと品物テーブルは問題の箇所ではないため省略しています。

問題点

ただ、上記のようなデータベース構造では送金記録テーブルの注文IDがない(NULL)パターンが発生することがあるので、外部キー制約にひっかかってしまい作成することができません。

NULLを許容するという方法も考えたのですが、調べたところ「極力nullはさけた方がいい(値ありか空値かnullかという確認がややこしくなるから)」と書かれていたため、not nullなデータベース構造にしたいと考えています。

今回の様なケースの場合でも、not nullなデータベース構造にすることはできるのでしょうか?
教えて頂ければ幸いです。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 6

+4

極力nullはさけた方がいい(値ありか空値かnullかという確認がややこしくなるから)

質問の根拠である上記の情報源は何でしょう?
「極力nullはさけた方がいい」については前提条件がありませんでしたか?

内容からすると、Not Null制約は付けるべきでは無いと思われます。

※どうしてもという事であれば、注文IDが取り得ない値をデフォルト値に設定することでしょうか。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+2

今回の様なケースの場合でも、not nullなデータベース構造にすることはできるのでしょうか?

「送金だけのダミーの注文を記録する」というような方法はあるかと思いますが、状況によっては余計に煩雑になる気はします。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/12/12 15:39 編集

    回答ありがとうございます。
    送金のみのダミー注文(と注文詳細)についてなのですが、1件だけダミー注文を作成して、送金記録を作成するとき「送金のみ」しかない場合は、このダミー注文IDを入れておけばいいということでしょうか?

    キャンセル

0

業務内容がよく分からないのですが、つまり「送金だけの注文がある」という事でしょうか?

あと、よくある設計としては、IDは1からにして、0を空と見るのもありますね。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/12/12 16:39

    回答ありがとうございます。
    nullの代わりになる値を入れて、not nullを表現するということですね。

    キャンセル

0

以前にも似たような質問がありましたのでリンクしておきます。
https://teratail.com/questions/157051">https://teratail.com/questions/157051

今回のケースではNULLを許容でよいと思います。
NULLを許容しないのであれば、注文なしでも注文なし用の注文テーブル・注文詳細のレコードを作るしかないのでは。
どちらもメリット・デメリットはあるので、業務内容から検討するしかないですね。
注文なしが頻発するのであれば、NULLを許容していないと注文テーブル・注文詳細にダミー的なレコードが溢れることになって管理しづらくなるとかあるかもしれません。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

モデルとして考えられているのはおそらく
[注文]0..1 ------ 0..*[送金記録]
だと思います。

現状の業務はそうなのでしょう。
しかし拡張性を考えると複数の注文に対して送金をまとめることも考慮しておくことをお勧めします。
[注文]0..* ------ 0..*[送金記録]
この場合には中間テーブルを作って多対多結合を表現します。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/12/12 15:55

    回答ありがとうございます。
    確かによくよく考えたら複数の注文をまとめるケースも
    発生するかもしれません。
    そう考えると、多対多にしとく必要がありますね。ついでに、中間テーブルを作ったことで送金記録テーブルの注文idカラムを作る必要がなくなり、nullの問題もなくなりますね。

    キャンセル

  • 2018/12/12 17:03

    売掛に対する入金なども多対多パターンを採用することが多いです。
    モデリングパターンは多いようでも、会計-経理-帳簿付けはわりと似たり寄ったりなのです。

    キャンセル

0

「一つの注文から複数の送金」に対して「複数の注文に対して一つの送金で済ます」
ことがあるかどうかで処理が変わります

正直注文テーブルにダミーで「注文なし」というレコードを1つ作っておけばよいだけのような気がしますが・・・

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.11%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る