> 実際のところ、データが無い状態をNULLで表現する手法は、使わないほうが良いのでしょうか? そのケースなら俺は普通に使う ただNULLの扱いは初心者にはちょっと直感に反するところがあるから注意が必要 https://codezine.jp/article/detail/5320767あ2017/10/27(金) 10:46:26.58ID:KUE3Fyml これは・・・・・面白い!!! https://blogs.yahoo.co.jp/antseq01/15073181.html0768NAME IS NULL2017/10/27(金) 11:19:35.89ID:7pjSfMZX>>765 リレーショナルデータベースではデータがない、値がないことを単にNULLと定義しているので、勘違いしないように。 0769NAME IS NULL2017/10/27(金) 11:41:03.34ID:??? 自分はNULL活用してるけどな
0や空文字 と 未定義(未入力) とは意味合いが違う フラグを別に設けるのも嫌だし
最近は言語側でも int? n; みたいなことが出来るようになって嬉しい 0770NAME IS NULL2017/10/27(金) 11:48:09.91ID:??? インデックスがねぇ 0771NAME IS NULL2017/10/27(金) 11:55:53.32ID:7pjSfMZX>>770 NULLを検索するという設計がおかしい。 0772NAME IS NULL2017/10/27(金) 12:42:08.79ID:??? あれ、WHERE 項目 IS NULL ってインデックス効かないの? 0773NAME IS NULL2017/10/27(金) 14:49:04.82ID:??? NULLを検索する設計がおかしいとは思わんが インデックスが効くかどうかはDBMSによる 0774NAME IS NULL2017/10/27(金) 14:52:48.92ID:??? 「とある項目が未入力のものを探す」という風なのだが、わざわざフラグ立ててやるの? 0775NAME IS NULL2017/10/27(金) 14:54:13.98ID:7pjSfMZX NULLを検索が多発している時点で考え方がおかしい。 0776NAME IS NULL2017/10/27(金) 14:58:18.06ID:7pjSfMZX>>774 言わんとすることはわかるが、なんで未入力とわかっている状態を検索して再度、確認する設計なのか? 0777NAME IS NULL2017/10/27(金) 14:59:19.82ID:??? だから、「とある項目が未入力のものを探す」という風なのだが、わざわざフラグ立ててやるの? 机上じゃなくて現実の運用場面を経験したことないのか? 0778NAME IS NULL2017/10/27(金) 15:01:04.60ID:???>>776 完全に入力が完了しないとコミットできない仕様(打ちかけを許容しない仕様)は ちょっとユーザーフレンドリーじゃないと思うよ? 0779NAME IS NULL2017/10/27(金) 15:24:58.30ID:7pjSfMZX>>777 そもそもNOT NULLにしなくてはいけないと思い込んでいる初心者の話だろうが? 0780NAME IS NULL2017/10/27(金) 16:22:16.25ID:???>>765 バグを生みやすいからNOT NULLにできるんならそうしたほうがいい といっても全部排除するにはそれなりの手間がかかるので落とし所を決める必要がある
単にデータが無い状態を表現する場合じゃなく データが「まだ」無い状態を表現する場合にNULLがよく使われる 簡単にデフォルト値が決められるようなものはNULL許容にしない 0781NAME IS NULL2017/10/27(金) 16:40:52.06ID:???>>778 入力完了済みのデータと入力途中のデータを一つのテーブルで管理するなら 完了済みかどうかの状態を管理するカラムを用意してそれを検索するんじゃないの? 特定のカラムがNULLだからXXという状態だと判断するって方法は極力避けたほうがいいと思うよ 0782NAME IS NULL2017/10/27(金) 16:53:00.08ID:7pjSfMZX>>780 変なこと言うな 0783NAME IS NULL2017/10/27(金) 16:55:39.17ID:7pjSfMZX NULL許容はC#用語か。RDB用語で言ってくれ。不親切。 0784NAME IS NULL2017/10/27(金) 18:42:11.20ID:???>>764 この流れを見れば ふいんき悪くしてるのが誰かアホでも分かるよね? 0785NAME IS NULL2017/10/27(金) 18:51:51.10ID:7pjSfMZX>>784 相当な小心者だな 0786NAME IS NULL2017/10/27(金) 18:53:20.75ID:??? この質問、例の人の自演だろ あんま相手しないほうが良さそう 0787NAME IS NULL2017/10/27(金) 18:53:29.86ID:??? はーい!ID :7pjSfMZX君でーす!! 0788NAME IS NULL2017/10/27(金) 19:21:39.36ID:??? nullはminとかmaxとかの集計関数で無視したい場合とか 更新が必要な項目で未更新状態の意味合いで使うな 0789NAME IS NULL2017/10/27(金) 20:01:02.67ID:??? そういえばオラクルはキー項目でもnull許可できる糞仕様だったな またオラクル使いか 0790NAME IS NULL2017/10/27(金) 20:47:43.07ID:??? Oracleでもさすがに主キーにNULLは入らない 外部キーには入るがそれは別に普通のこと
それよりOracleは長さゼロの文字列とNULLが同じ意味になるという 糞仕様をいつまでも捨てられずにいることが問題 0791NAME IS NULL2017/10/27(金) 20:50:02.76ID:n2vV1nnl>>790 地雷だな、それって 0792NAME IS NULL2017/10/27(金) 21:07:35.53ID:??? ま〜たこうやって、ボラクルの話になっていくのであった。 0793NAME IS NULL2017/10/27(金) 21:31:19.54ID:???>>788 >nullはminとかmaxとかの集計関数で無視したい場合 条件で絞ればいいだけじゃないの? 0794NAME IS NULL2017/10/27(金) 22:49:58.72ID:??? 正規化してテーブルを増やしてデータの一貫性を保ちやすくするのは解ったんですが テーブル増やしたらデータを追加するとき複雑になりませんか? あっちのテーブルに日付情報入れて利用者IDいれてこっちのテーブルに金額入れてとか混乱しそうな気がしますが 0795NAME IS NULL2017/10/28(土) 00:43:45.46ID:SXU3olx1>>784 え?ふいんき悪いのか?アホ的には? 0796NAME IS NULL2017/10/28(土) 04:44:21.82ID:??? NULL使わない人はデータが無い状態をどうやって表現するのですか? 0797NAME IS NULL2017/10/28(土) 06:49:50.86ID:??? リレーションを分ける 0798NAME IS NULL2017/10/28(土) 08:02:48.10ID:??? NULLは必要だよ。 例えば日付型の生年月日があるとして、 NOT NULL なら default値はどうすんの? 0799NAME IS NULL2017/10/28(土) 08:28:03.58ID:???>>797 kwsk 0800NAME IS NULL2017/10/28(土) 08:50:09.46ID:??? create table T ( pkey int primary key, a int not null, b int null )
こんなリレーションなら下のように分ける
create table TA ( pkey int primary key, a int not null )
create table TB ( pkey int primary key, b int not null )
元のaがnot nullでbがnullという条件はTBからTAへの外部参照制約で表現できる 0801NAME IS NULL2017/10/28(土) 11:10:00.12ID:qpJvhhHo>>800 それは方言のじゃないのか? 0802NAME IS NULL2017/10/28(土) 11:28:57.57ID:??? どこのこと? 0803NAME IS NULL2017/10/28(土) 11:37:56.32ID:???>>800 いちいちそんな面倒なことやってんの? 0804NAME IS NULL2017/10/28(土) 12:35:01.35ID:??? NOT NULL縛りの是非はともかく、手間としては正規化とたいして違わない気がするが。 正規化を「いちいちそんな面倒なこと」と言う奴は少ないだろう。 0805NAME IS NULL2017/10/28(土) 12:58:56.42ID:??? 違うだろ〜 ハゲ〜 0806NAME IS NULL2017/10/28(土) 13:31:18.62ID:??? null 可能列が10個あったら表が10個増えるのか w まあ頑張れやとかしか言えない 0807NAME IS NULL2017/10/28(土) 14:56:15.88ID:??? 単純に10個増えるとは限らないよ
派生関係でうまく処理できる場合もあるけど 任意項目があるたびに派生関係を作っていくのはあまり現実的ではないよね 0808NAME IS NULL2017/10/28(土) 15:58:18.89ID:??? 思いつきでアホなこと言ったばかりに言い訳が苦しいなw 08098072017/10/28(土) 16:39:43.64ID:???>>808 俺は派生関係提示したやつと別人だぞ 0810NAME IS NULL2017/10/28(土) 19:05:25.10ID:???>>800 で、外部結合して結局項目bがNULLになるのな 0811NAME IS NULL2017/10/28(土) 19:34:58.65ID:Nv4Gn8Ik ID 強制表示に出来ないのかな 0812NAME IS NULL2017/10/28(土) 19:51:25.60ID:???>>810 ならなかったらそもそも>>796への答にはならんだろ 0813NAME IS NULL2017/10/28(土) 19:58:00.37ID:SXU3olx1 そもそも「データが無い状態」という情報をどうしても記録しておかなければいけない状況ってのはそうそうない そのシステムの性質にもよるけど 0814NAME IS NULL2017/10/28(土) 20:06:21.77ID:??? 閉世界が前提だから、「データがある」状態だけ記録しておけばそれが存在しなければ「無い」だと思うが。 明示的に「無い」ことを記録しているわけじゃないだろう。 0815NAME IS NULL2017/10/28(土) 20:55:50.54ID:SXU3olx1>>814 いやそういう禅問答的な屁理屈を言われても「その通りですね」としか言えんけどw 何か反論したい事でもあるの? 0816NAME IS NULL2017/10/28(土) 21:10:26.14ID:???>>812 外部結合の結果とはいえ、デーが無い場合はNULLになるってことだ 直接テーブルに入れてないとは言えNULL使ってるわけだから>>796の回答足り得てないと思うけど? 0817NAME IS NULL2017/10/28(土) 21:19:58.09ID:???>>815 データが無いことを記録する必要があるかどうかという問い自体がナンセンスということ。 0818NAME IS NULL2017/10/28(土) 21:22:55.68ID:???>>812 それってb列に直接null入れるとのたいして違わなくね? 0819NAME IS NULL2017/10/28(土) 21:29:12.67ID:???>>816 NOT NULLにしたとしても外部結合したらNULL発生しうるじゃん そうすると>>796への回答足り得ないの? 0820NAME IS NULL2017/10/28(土) 21:30:47.78ID:??? 派生関係はNULLを使わないために導入するものじゃないから話が噛み合わないのかもね 0821NAME IS NULL2017/10/28(土) 21:38:29.64ID:SXU3olx1>>817 ん?つまりnot null制約自体の存在を否定したいのか? 0822NAME IS NULL2017/10/28(土) 21:59:40.59ID:??? 「データが無いことを記録する」手段が唯一NULL許可フィールドのみなのであれば NOT NULL制約と関係なくはないのかもしれんが、まぁ、関係ないよな。 0823NAME IS NULL2017/10/28(土) 22:05:56.46ID:SXU3olx1>>822 いや論じる事がナンセンスなんだろ? その事と関係あるとかないとか唯一とか関係ないよね? お前は何を言いたいの? 0824NAME IS NULL2017/10/28(土) 22:16:58.96ID:??? 質問者の>>796、とりあえずどうにか話の方向をどうにかしてくれよ。 nullの話は簡単に結論が出るようなもんじゃないんで、いつまでも続けられても鬱陶しいだけなんだ 0825NAME IS NULL2017/10/28(土) 22:30:08.58ID:??? 人と違ったことを言わないと気がすまない人っているね 俺は俺はってw 0826NAME IS NULL2017/10/28(土) 22:41:07.11ID:??? こんな過疎スレで話が続いても誰も困らんだろ それより質問者を含めスレ読んでるやつが 多くの選択肢を知ることができるほうが意義があると思うぞ 0827NAME IS NULL2017/10/28(土) 22:50:23.13ID:??? 禅問答は傍で見ているとうざいが、かといってテーブル10個作るのは面倒だなんてレベルの話ばっかりでもなぁ。 0828NAME IS NULL2017/10/28(土) 23:15:38.46ID:???>>823 「必要性があるとないとにかかわらず、意図的に「記録」するまでもなく、 「データが無い状態」というのはデータベース上のデータ自体で表現される ものだから、>>813で書いている言明はそもそも意味がない」
本来なら「その通りですね」で終わってた話。 0829NAME IS NULL2017/10/28(土) 23:23:38.74ID:SXU3olx1>>828 いやだから何を言いたいのお前?w 0830NAME IS NULL2017/10/28(土) 23:25:21.73ID:???>>827 おまえの頭が低レベルすぎるだけ 0831NAME IS NULL2017/10/29(日) 00:03:43.84ID:???>>827 無意味なテーブル作るのなんか、たとえ1個でも願い下げだわ 作るのが面倒とか以前の問題 0832NAME IS NULL2017/10/29(日) 03:06:41.55ID:???>>819 >>796は、NULL使わない場合を想定した質問だぞ データがない場合はNULLですだと、そもそもの質問の前提が成り立ってない >>820 >NULL使わない人はデータが無い状態をどうやって表現するのですか? に対する答えとして派生関係を出してきたはずだが >>828 意図的にデータがない状態を記録するのに、NULLを使う手法はありかなしかって話をしてたんだと思うけど そんな要件は現実的にあり得ないってならまあその意見もわからんではないが 実際のシステム設計じゃままある要件なんだがな
いい加減スレ違いなのは確かだし、これ以上は設計スレあたりで 0833NAME IS NULL2017/10/29(日) 05:22:45.25ID:??? ちょっとした疑問なんだが、
select group.name as group_name, team.name as team_name, user.name as user_name from user_table as user inner join group_table as group on group.id=user.group_id inner join team_table as team on team.id=user.team_id
select group.group_name as group_name, team.team_name as team_name, user.name as user_name from user_table as user inner join group_table as group on group.group_id=user.group_id inner join team_table as team on team.team_id=user.team_id
テーブル構成がおかしいとか、on句の書き方が気にくわないとか色々あるだろうけど、一先ず置いといて、 命名として、どっちなんだろうなと思って 0834NAME IS NULL2017/10/29(日) 08:05:20.25ID:???>>836 JOINの結果NULLが現れるから回答になってないってのはさすが屁理屈が過ぎるだろう。 >>796の前まではフィールドのNOT NULL制約について話していたわけだし、>>796も それを踏まえた質問ととらえるのが自然。 0835NAME IS NULL2017/10/29(日) 10:01:25.63ID:???>>833 どっちが主流かは知らんけど俺はパターン1 0836NAME IS NULL2017/10/29(日) 22:04:41.05ID:???>>833 プライマリキーとそれ以外のカラムでは扱いが違う プライマリキー以外のカラムにテーブル名を単純なプリフィクスとして使う人は少ない
生SQL扱うなら、本来の考え方からいけば2だろうな 0843NAME IS NULL2017/10/30(月) 21:20:22.79ID:bh4tIMwn SQL Serverの管理ビューは1で Oracleのデータディクショナリは2だな 他のDBMSはどうだろう 0844NAME IS NULL2017/10/30(月) 22:29:55.78ID:???>>842 なにそのオレオレ本来の考え方って? 0845NAME IS NULL2017/10/30(月) 22:34:48.02ID:??? 論理レベルで複合キーやナチュラルキーのテーブルを 物理レベルでどう扱いたいかが重要な分岐点 0846NAME IS NULL2017/10/31(火) 02:45:10.98ID:???>>844 同じものには同じ名前をつける 違うものには違う名前をつける これが原則
たとえば標準単価と販売単価を、同じ単価と言う項目名で定義するのはよろしくないだろ
ここ設計スレじゃないしこれ以上はどっか別のスレでよろしく 0847NAME IS NULL2017/10/31(火) 06:28:26.89ID:???>>846 何で列名だけで判断してるんだ? 標準価格.単価 と 販売価格.単価 が同じものに見えるなら病院に行った方がいい 0848NAME IS NULL2017/10/31(火) 07:03:48.58ID:1FOujQPV 先入観に汚染されてるなw 0849NAME IS NULL2017/10/31(火) 07:07:19.92ID:???>>847 なんだこのバカw 0850NAME IS NULL2017/10/31(火) 11:39:03.51ID:IzoEenp0>>847 それはRDBの考え方ではない。 0851NAME IS NULL2017/10/31(火) 13:26:32.03ID:??? そんな紛らわしいこと実務でやる奴いたら、とっちめられるぞ 0852NAME IS NULL2017/10/31(火) 13:46:14.10ID:???>>846 何をもって同じとするのか 何をもって違うとするのかの基準が違うから id派とuser_id派に分かれるんだよね
例えば各テーブルに内部的な管理用としてレコードの更新日時を記録する場合 最終更新日時とかの名前でどのテーブルも同じカラム名でも別におかしくない レコードの更新日時という意味で同じだから id派の考えはその延長 0853NAME IS NULL2017/10/31(火) 14:13:44.10ID:??? create table T ( nk1 int PK, -- nk = Natural Key nk2 int PK, nk3 int PK, nk4 int PK, a int not null, b int null, c int null )
create table TA ( nk1 int PK, nk2 int PK, nk3 int PK, nk4 int PK, a int not null )
create table TB ( nk1 int PK, nk2 int PK, nk3 int PK, nk4 int PK, b int not null )
create table TC ( nk1 int PK, nk2 int PK, nk3 int PK, nk4 int PK, c int not null ) 0854NAME IS NULL2017/10/31(火) 14:48:11.62ID:IzoEenp0>>852 無理矢理すぎる理屈だな。
登録・更新者、登録・更新日時の項目は、結合項目として使用するなどどいう話は、あなたの中でもないだろうに。 0855NAME IS NULL2017/10/31(火) 15:56:39.69ID:HRkll2T3 そうかなあ テーブル名もカラム名の属性を表してるわけで テーブル名をテキトーにつけてなけりゃ 情報の一部だべ 0856NAME IS NULL2017/10/31(火) 16:15:00.47ID:??? >標準価格.単価 と 販売価格.単価 テーブル名まで書くんだったら、最初から >標準価格 と 販売価格 で良いんでは 0857NAME IS NULL2017/10/31(火) 16:32:16.66ID:IzoEenp0>>855 テーブルの論理名はエンティティ名といって、適当に名前をつけていたら、混乱するだけでよいことはない。 0858NAME IS NULL2017/10/31(火) 16:33:04.70ID:IzoEenp0>>856 彼はオブシェクト指向とごっちゃになっているのだろう。 0859NAME IS NULL2017/10/31(火) 16:53:50.50ID:??? 価格というテーブルがあって
という風なら理解できるぞい 0860NAME IS NULL2017/10/31(火) 19:43:13.45ID:mnuaDWX/>>859 価格というテーブルには、 標準価格か販売価格のどちらかしか 入らなくなりませんか? 0861NAME IS NULL2017/10/31(火) 21:27:26.45ID:??? user_id派は昔ながらのリレーショナルモデル、id派はERモデルの発想だろう。 そのへん区別できてない人も多いけどな。 0862NAME IS NULL2017/10/31(火) 21:34:56.59ID:???>>849-850 爺は早めにくたばれよ w