0738NAME IS NULL2017/10/21(土) 09:58:25.58ID:y12hXRx2>>737 他人のせいすんなクズw 0739NAME IS NULL2017/10/21(土) 18:51:28.16ID:???>>733 だいたいどのDBMSでもできるよ 0740NAME IS NULL2017/10/21(土) 22:04:08.59ID:??? 確かにID無しだけ見ると平和な良スレだな 0741名無しさん@そうだ選挙に行こう! Go to vote!2017/10/22(日) 15:51:36.27ID:???>>733 できるのか できるということはシステム的には問題ないって事だな 分かりにくくなったり手間が増えるかもしれんが
主キーは全部”ID”派の人はしらん まあそう言う人は主キー制約の名前なんてそれこそ自動付加でいいんだろう 0742名無しさん@そうだ選挙に行こう! Go to vote!2017/10/22(日) 16:42:01.36ID:???>>741 PKはテーブルに一つなのと制約名で重複しちゃダメなDBMSがほとんどなので 自動付与じゃなければPK_tablenameみたいにテーブル名を入れといたほうがいい インデックスと違ってPK制約名からどの列がPKなのかを知りたいって人いないよね?
それに他の制約名と違ってPK制約名は意識的に扱うことが基本ないから自動付与で十分なことが多い SQL ServerやPostgresなんかは自動付与でも分かりやすい名前になる 0743名無しさん@そうだ選挙に行こう! Go to vote!2017/10/22(日) 19:04:47.81ID:B6C5gZpT 今回初めて知って嬉しいのはわかるけどこんなにいつまでも引っ張るような話題ではない 0744NAME IS NULL2017/10/22(日) 20:01:12.98ID:??? はいはい 自称プロなら管理の都合上、ちゃんと名前つける( ー`дー´)キリッ だもんねww 0745NAME IS NULL2017/10/22(日) 20:58:53.03ID:??? 話題としては意味はあるけど、SQL質疑応答スレでやる内容ではないな 0746NAME IS NULL2017/10/22(日) 22:38:37.90ID:B6C5gZpT あまのじやくやのうw 0747NAME IS NULL2017/10/22(日) 23:05:36.02ID:hqoDUL2z すっごい不評なegov法令検索を設計したのは名古屋大学の外山教授ですか? 不評過ぎます 0748NAME IS NULL2017/10/22(日) 23:07:02.13ID:hqoDUL2z すっごい不評な法令検索つくったくせに賞をもらっている意味不明な教授ですか? 0749NAME IS NULL2017/10/22(日) 23:53:08.71ID:??? データベース板でID見えてるやつは地雷であり荒らしよ 無視推奨 0750NAME IS NULL2017/10/23(月) 00:27:40.32ID:mf1jBI9V 豊田真由子様に罵倒されたい 0751NAME IS NULL2017/10/23(月) 13:55:18.88ID:??? JavaでSQL書いてRDB使いまくりたいんですがそうなるためにこれ読んどけ見たいなのありませんか? DBにデータを記憶するのはもちろんDBから数値や文字列を取り出してjava側で変数に代入したりして使いこなせるようになりたいです。 0752NAME IS NULL2017/10/23(月) 15:29:30.92ID:CzSV0ugc>>751 そのRDBが何なのか? 0753NAME IS NULL2017/10/23(月) 15:53:41.99ID:???>>751 JDBCの使いかたはわかってる? 0754NAME IS NULL2017/10/23(月) 17:30:16.82ID:???>>752 どれ使って良いかよく解らないんですが今はスッキリ解るシリーズのSQLの本読んでます。 MySQLかpostgreSQLがよさそうだなと思いますがSQLserverの無料版もよさそうだなと思って迷ってます。 >>753 使い方はよく解りませんがJDBCって言うの使えばどのDBMSでも多少ルールが違えど似たような扱いができるんですよね? スッキリ解るシリーズの実戦編に少し書いてあった気がしますがほんの少しだけだった気がします。 なんかJavaとDBの連携した使い方がみっちりつまった本ってありませんか?初学者でもわかるようなので・・・ 0755NAME IS NULL2017/10/23(月) 17:33:48.73ID:ZhgI//rN その選択肢はWindowsで動かす予定かな DBはDBで単体でまず扱えるようにならないとあとあときついよ 0756NAME IS NULL2017/10/23(月) 17:46:09.06ID:???>>754 Javaデータアクセス実践講座
中で使ってるのはMySQL
javaとSQLがそれぞれわかっていることが前提条件になっているとは思う 一応これでJavaからMySQLに接続してどうのこうのってのは出来るようになった。 0757NAME IS NULL2017/10/23(月) 20:14:17.85ID:mf1jBI9V Javaというより、RDBの勉強の方がいいと思うけどな。JavaとRDBのやり取りは、知らないフレームワークを介さないのであれば難しいわけではない。 0758NAME IS NULL2017/10/23(月) 20:48:54.31ID:???>>757 >知らないフレームワークを介さないのであれば
学ばないでいつ知るんだよw JDBCならともかくHibernateにしろSpring Data JPAにしろ 中身を把握するにはそれ相応の学習コストが必要 0759NAME IS NULL2017/10/23(月) 21:09:51.32ID:mf1jBI9V>>758 JDBC以外は全部、Java EEじゃないんですけど?
JDBCと言ってるのにいきなり謎のフレームワークを使えとはトレーナーとしてもありえない。 0760NAME IS NULL2017/10/24(火) 01:31:44.05ID:??? 謎のフレームワーク? 0761NAME IS NULL2017/10/24(火) 02:12:17.03ID:Ftk4ZC9L>>754 は超初心者だぜ? 0762NAME IS NULL2017/10/24(火) 07:23:26.08ID:???>>756 ありがとうございます。その本買ってみます。 0763NAME IS NULL2017/10/24(火) 16:01:08.70ID:???>>759 トレーナーとして? プロの次はトレーナー 0764NAME IS NULL2017/10/26(木) 00:31:39.63ID:Z3UH5ceX なんでそんなにプロにつっかかるん? ふいんき悪くなるからやめたら? 0765NAME IS NULL2017/10/27(金) 10:04:02.60ID:??? SQL初心者です。 カラムをNULL許容型にするのは良くないと言った説明をいろんなサイトで見ます。 実際のところ、データが無い状態をNULLで表現する手法は、使わないほうが良いのでしょうか? DBを使いまくっている専門家の人の意見をお聞かせください。 0766NAME IS NULL2017/10/27(金) 10:41:51.90ID:???>>765 専門家じゃないけど
> 実際のところ、データが無い状態を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 プライマリキーとそれ以外のカラムでは扱いが違う プライマリキー以外のカラムにテーブル名を単純なプリフィクスとして使う人は少ない