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

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

ただいまの
回答率

89.10%

テーブルにデフォルトでNLLLを入れますか?

解決済

回答 4

投稿 編集

  • 評価
  • クリップ 0
  • VIEW 318

yakan

score 16

テーブルに以下
nameA、nameB のいずれかが入るカラムがあるとします。
mytable2_ID、my_table3_ID のいずれかが入るカラムがあるとします。

CREATE TABLE IF NOT EXISTS mytable1 (
ID INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
mytable2_ID INT(10), # いずれかが入る
mytable3_ID INT(10),  # いずれかが入る
FOREIGN KEY (mytable2_ID) REFERENCES mytable2(ID),
FOREIGN KEY (mytable3_ID) REFERENCES mytable3(ID)


こういった場合、下記のようにDEFAULT NULLを設定すべきでしょうか?

CREATE TABLE IF NOT EXISTS mytable1 (
ID INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
mytable2_ID INT(10) DEFAULT NULL,
mytable3_ID INT(10) DEFAULT NULL,
FOREIGN KEY (mytable2_ID) REFERENCES mytable2(ID),
FOREIGN KEY (mytable3_ID) REFERENCES mytable3(ID)


いまいちNULLのメリットやデメリットが理解できておりません…
あると何が便利なのでしょうか?

修正

誤解があったため内容を次のように修正させていただきます。
「NULL」か「空文字列」か、どちらにすべきか?でした。
ご指摘頂いたmaisumakun様、ありがとうございます。

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

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

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

    クリップを取り消します

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

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

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

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

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

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

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

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

    質問の評価を下げる

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

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

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

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

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

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

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

    詳細な説明はこちら

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

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

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

回答 4

checkベストアンサー

+1

値が与えられなければ、必然的にNUllになるので、敢えて指定する必要は無く、また敢えてDEFAULT Nullにする場面は思いつきません。

例に挙げているテーブルで、何れか一方がNot Nullでもう一方はNUllという事なら、それは制約で定義するものですし、設計としてなら、値とその識別(A or B)というテーブル設計であるべきでしょう。

追記

質問の内容から、用いられるSQLは以下を想定されているのだと思います。

A.

select *
from  mytable1 t1
      left join mytable2 t2
      on  t1.mytable2_ID=t2.id
      left join mytable3 t3
      on  t1.mytable3_ID=t3.id


この場合、外部キー制約により片側一方が設定されない場合の値(例えば0)をmytable2 や3に値として登録しておく必要があります。

B.

テーブル構造を

CREATE TABLE IF NOT EXISTS mytable1 (
ID INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
type int(1) not null, -- mytable_idの参照先(0:mytable2, 1:mytable3)
mytable_ID INT(10) not null
)


のようにした場合、外部キーの設定はできませんが、必須が担保されるので、default値は不要になります。
また、問い合わせは以下の様になります。

select *
from  mytable1 t1
      left join mytable2 t2
      on  t1.type=0 and t1.mytable_ID=t2.id
      left join mytable3 t3
      on  t1.type=1 and t1.mytable_ID=t3.id


A.の問い合わせに関して適切にインデックスを適用しようとするなら
(mytable2_ID),(mytable3_ID)の2つのインデックスが必要です。
(mytable2_ID , mytable3_ID)のインデックスでは効率的ではありません。
この2つのインデックスを適用する為にはunionを使用する必要があります。

selectfrom  mytable1 t1
      inner join mytable2 t2
      on  t1.mytable2_ID=t2.id
union all
selectfrom  mytable1 t1
      inner join mytable3 t3
      on  t1.mytable3_ID=t3.id


union ですから、当然select項目は数を合わせなければなりません。

一方、B.の問い合わせ関しては、(type, mytable_ID)のインデックスを用意するだけです。

投稿

編集

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2020/06/29 23:31

    追記しました。
    あくまで理論上ですので、ある程度の件数のデータを用いた実行計画で、確認した方が確実ですけど。

    キャンセル

  • 2020/06/29 23:36 編集

    > 整合の方はSELECTをかけないといけませんよね。
    mytable2 や3に整合を掛ける必要があるとするなら、その場合の操作としては、mytable2 や3の内容を選択させるような処理になるのではないですか?
    それなら選択する時点で整合はとれますので、さらにチェックするのは冗長です。

    キャンセル

  • 2020/06/30 07:19 編集

    あれもこれも仰る通りで、いろいろなケースを考えてみましたがすべて選択してからINSERTされるものでしたので、おかげ様で外部キーが冗長だったと気付けました。typeの構造で進めていきたいと思います。度々のご返信、誠にありがとうございました。

    キャンセル

0

いまいちNULLのメリットやデメリットが理解できておりません…
あると何が便利なのでしょうか?

まず、基本的にNULLの完全に排除する事は非常に難しいものの、極力利用を避けるように設計する方が望ましいという意見がありますし、個人的にも概ね同意します。

ちょっとググれば色々な意見が出てくると思いますが、例えばNULL撲滅委員会などを読んでみて下さい。

また、質問文の場合はそもそものテーブル設計がおかしい可能性があります。どのようなエンティティかわからないので一概には言えませんが、nameAとnameBはそれぞれ別テーブルに分けて必要に応じてJOINするような設計の方が直感的には良さそうな気がします。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2020/06/29 16:47

    「極力利用を避けるように設計する方が望ましい」ですが、それは「空」のままという意味ですか?
    それとも後半で仰っているように別テーブルにして「NOT NULL」にすべきという意味ですか?

    後者ならば、今回はテーブルを別にわけない場合についてお聞きしたいと思っていたのですが、「空」か「NULL」かいずれがよろしいでしょうか?

    キャンセル

  • 2020/06/29 16:49

    > 後者ならば、今回はテーブルを別にわけない場合についてお聞きしたいと思っていたのですが、「空」か「NULL」かいずれがよろしいでしょうか?

    NULLでない「空」という状態は、そもそも存在しません。NOT NULLであれば、何かしらの値を詰める必要があります。

    キャンセル

0

下記のようにDEFAULT NULLを設定すべきでしょうか?

逆に質問しますが、両方の列をNOT NULLに設定して、値が入らないところには何を入れるつもりなのでしょうか?

「テーブルを分けない」条件では、NULLを許容する他ありません。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2020/06/29 17:02

    >両方の列をNOT NULLに設定して
    nameA、nameBはいずれかが入るカラムなので、「両方の列をNOT NULLに設定」はしないです。

    >値が入らないところには何を入れるつもりなのでしょうか?
    DEAFAULT NULLを指定しないという意味で、特に何も入れず、「空」という状態にしようと考えています。

    >NULLでない「空」という状態は、そもそも存在しません
    なるほど、DEAFAULT NULLを指定しなければ、それは自動でDEAFAULT NULLになるのですね。

    キャンセル

  • 2020/06/29 17:17

    あれ?
    やはり「空」という状態はありました。下図の赤がそれで、緑が「NULL」です。
    https://imgur.com/a/ON5PGZW

    キャンセル

  • 2020/06/29 17:19

    空文字列が入っている状態ではないでしょうか?

    キャンセル

  • 2020/06/29 17:20

    なるほどこれは「空文字列」という状態でしたか。それでは質問を変えなければなりませんね…
    「NULL」にすべきか?「空文字列」にすべきか?というのが質問したかったことでした。
    そうなりますといかが思われますでしょうか?
    何度も申し訳ございません。

    キャンセル

0

例えば氏名の場合、日本では姓と名ですが、欧米ではミドルネームが存在しますね。
しかもミドルネームはない人もいます。
※日本人ハーフの場合、姓か名のどちらかにミドルネームをくっつけてますね。田中マルクス闘莉王さんとか、ケンブリッジ飛鳥アントニオさんとか。

ですからテーブル定義上、ミドルネームは null を許可しなくてはならないでしょう。
※別の手としてはミドルネームだけ別テーブルにして、1対 (0or1) の結合をとる手もありますが

むろんこのような場合にミドルネームを空文字列('')として登録する運用でもできなくはないですが。

すでに他の方が書いていますが、質問のような場合は、テーブル設計を見直すべきではあります。
nameA と nameB のどちらかしか入らないなら、name と「どちらに入れるのか」を記録するようにするとか。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2020/06/29 17:14

    >ミドルネームは null を許可しなくてはならないでしょう
    なるほど、カラムの値としては「null」以外に「空」という何も入っていない状態があるものと思っておりました。しかしそういった状態はなく、何も入っていなければそれは強制的に「null」になるのですね。

    キャンセル

  • 2020/06/29 17:27

    データベースにおいて「null」とは、特別な状態です。それは本当に「何もない」ことを示しているのであって、空文字列('')とも違うものなのです。
    null は何と比較しても true にも false にもならず null になる(null とでさえも)ので、扱いには注意が必要です。
    ※where {カラム} = null は、いかなる場合でも成立しない。そのために特別な演算子 is null があったり、MySQL のように null 比較安全な演算子 <=> が定義されていたりする

    キャンセル

  • 2020/06/29 17:32

    だから IS NULL が必要だったのですね。いつも where {カラム} = null ができないことに納得できていなかったのでスッキリいたしました。

    キャンセル

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

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