前提・実現したいこと
データベースには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ページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
+4
極力nullはさけた方がいい（値ありか空値かnullかという確認がややこしくなるから）
質問の根拠である上記の情報源は何でしょう？
「極力nullはさけた方がいい」については前提条件がありませんでしたか？
内容からすると、Not Null制約は付けるべきでは無いと思われます。
※どうしてもという事であれば、注文IDが取り得ない値をデフォルト値に設定することでしょうか。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+2
今回の様なケースの場合でも、not nullなデータベース構造にすることはできるのでしょうか？
「送金だけのダミーの注文を記録する」というような方法はあるかと思いますが、状況によっては余計に煩雑になる気はします。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
0
業務内容がよく分からないのですが、つまり「送金だけの注文がある」という事でしょうか？
あと、よくある設計としては、IDは1からにして、0を空と見るのもありますね。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
0
以前にも似たような質問がありましたのでリンクしておきます。
https://teratail.com/questions/157051">https://teratail.com/questions/157051
今回のケースではNULLを許容でよいと思います。
NULLを許容しないのであれば、注文なしでも注文なし用の注文テーブル・注文詳細のレコードを作るしかないのでは。
どちらもメリット・デメリットはあるので、業務内容から検討するしかないですね。
注文なしが頻発するのであれば、NULLを許容していないと注文テーブル・注文詳細にダミー的なレコードが溢れることになって管理しづらくなるとかあるかもしれません。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
0
モデルとして考えられているのはおそらく
[注文]0..1 ------ 0..*[送金記録]
だと思います。
現状の業務はそうなのでしょう。
しかし拡張性を考えると複数の注文に対して送金をまとめることも考慮しておくことをお勧めします。
[注文]0..* ------ 0..*[送金記録]
この場合には中間テーブルを作って多対多結合を表現します。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
0
「一つの注文から複数の送金」に対して「複数の注文に対して一つの送金で済ます」
ことがあるかどうかで処理が変わります
正直注文テーブルにダミーで「注文なし」というレコードを１つ作っておけばよいだけのような気がしますが・・・
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
15分調べてもわからないことは、teratailで質問しよう！
- ただいまの回答率 88.11%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる