SQL質疑応答スレ 17問目 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
このスレは
「こういうことをやりたいんだけどSQLでどう書くの？」
「こういうSQLを書いたんだけどうまく動きません＞＜」
などの質問を受け付けるスレです。
SQLという言語はISOによって標準化されていますが
この標準を100%実装したDBMSは存在せず、
また、DBMSによっては標準でない独自の構文が
追加されていることもあります。
質問するときはDBMS名を必ず付記してください。
【質問テンプレ】
・DBMS名とバージョン
・テーブルデータ
・欲しい結果
・説明
前スレ：
SQL質疑応答スレ 16問目
http://echo.2ch.net/test/read.cgi/db/1447160858/ 主キー列名、主キー制約名、インデックス名がちゃんと説明できるレベルの人は、この板にはほとんどいない。 create table hoge (id integer primary key)
とした場合、制約名はシステムが勝手につけた名前になる
create table hoge (id integer constraint hage primary key)
とすると制約名はhageとなる >>711
SQLは同じ名前の列は、同じ属性と見なすから標準SQLでもナチュラルジョインがあるわけで、良いはずがない。 >>713
あんたどのRDBMSの方言で説明してんの？ >>708
お、そう
それはアンチパターンだね
>>710
トレードオフだからね
君はそれを知らないだけ >>716
何がトレードオフだよ。自分自身の関心事かそうでないかだろ。
有名なフレームワークやパッケージでもDBにうといのか、ひどい設計はよくある。 >>708
ごっちゃにはなっていません。
最初の質問に書いたように列名と主キー名をあえて同じにすると何か困る事が有るかどうかを知りたかったのです。私はPK_派です。 >>720
「主キー名」って何を指しているの？ 主キー制約の名前？ 制約名は重要なものじゃないから自動でつけられるだろ。制約だけ削除したい時にしか使われないと思う。
だから好きにすればいい。 >>722
なるほど。その言葉の使い分けはとても重要なので今後気をつけてー >>720
主キー制約のことを単に「主キー」とは呼ばないから
それだけは覚えといてよ 試したことも試そうと思ったことも無いけど、制約名ってカラム名とかぶっても大丈夫なのか？
それと他のテーブルとかぶっても良いのか？
SQLServerの2008R2だと
>制約名は、テーブルが所属するスキーマ内で一意である必要があります。
って書いてあるんだが だめだから自動のはSYS_連番とかになってるよね
自動付与のやつだとキー重複とかでエラーになったとき
エラーログとかでぱっとわからないからPK_表名にしてる。
インデックスの名前付けにいつも悩む。
表とか列とかつなげてくと長くなるし・・ 自称プロはOracleしか知らなそうだし、Oracle知らなそう >>730
自分は意味のあることは書かず、他人批判、もっと言えば第三者から見ても嫌なやつと思われる言動をするのは、よほどひねくれているぞ。 >>723
制約が重要でない？
まあ汎用機世代の人間がテーブル名もカラム名も重要ではないと言うのと同じ感覚なのか？ >>728
そもそもの>>689の話は、制約名を列名と同じにするって話じゃなかったのか
できるDBある？そんなことはできないで終わりの話じゃないのか DMLで多用するテーブル名、カラム名と基本的にDDLでしか使用しない制約名、インデックス名とじゃ
命名の重要度が違うのは当然だろう。 >>731
批判に見えましたか！
自覚があるんやなぁ 案の定質問の意味すらわからない奴が答えたがって場を荒すいつものパターンw >>733
できるのか
できるということはシステム的には問題ないって事だな
分かりにくくなったり手間が増えるかもしれんが
じゃあ、ＰＫ列名を全テーブルに対してユニークにする派の人なら
PK制約名をPKのカラム名と同じにするでもいいんじゃね
複合主キーどうするとかあるけどな
主キーは全部”ID”派の人はしらん
まあそう言う人は主キー制約の名前なんてそれこそ自動付加でいいんだろう >>741
PKはテーブルに一つなのと制約名で重複しちゃダメなDBMSがほとんどなので
自動付与じゃなければPK_tablenameみたいにテーブル名を入れといたほうがいい
インデックスと違ってPK制約名からどの列がPKなのかを知りたいって人いないよね？
それに他の制約名と違ってPK制約名は意識的に扱うことが基本ないから自動付与で十分なことが多い
SQL ServerやPostgresなんかは自動付与でも分かりやすい名前になる 今回初めて知って嬉しいのはわかるけどこんなにいつまでも引っ張るような話題ではない はいはい
自称プロなら管理の都合上、ちゃんと名前つける( ｰ`дｰ´)ｷﾘｯ
だもんねww 話題としては意味はあるけど、SQL質疑応答スレでやる内容ではないな すっごい不評なegov法令検索を設計したのは名古屋大学の外山教授ですか？
不評過ぎます すっごい不評な法令検索つくったくせに賞をもらっている意味不明な教授ですか？ データベース板でID見えてるやつは地雷であり荒らしよ
無視推奨 JavaでSQL書いてＲＤＢ使いまくりたいんですがそうなるためにこれ読んどけ見たいなのありませんか？
DBにデータを記憶するのはもちろんＤＢから数値や文字列を取り出してjava側で変数に代入したりして使いこなせるようになりたいです。 >>752
どれ使って良いかよく解らないんですが今はスッキリ解るシリーズのＳＱＬの本読んでます。
MySQLかpostgreSQLがよさそうだなと思いますがSQLserverの無料版もよさそうだなと思って迷ってます。
>>753
使い方はよく解りませんがＪＤＢＣって言うの使えばどのＤＢＭＳでも多少ルールが違えど似たような扱いができるんですよね？
スッキリ解るシリーズの実戦編に少し書いてあった気がしますがほんの少しだけだった気がします。
なんかJavaとDBの連携した使い方がみっちりつまった本ってありませんか？初学者でもわかるようなので・・・ その選択肢はWindowsで動かす予定かな
DBはDBで単体でまず扱えるようにならないとあとあときついよ >>754
Javaデータアクセス実践講座
中で使ってるのはMySQL
javaとSQLがそれぞれわかっていることが前提条件になっているとは思う
一応これでJavaからMySQLに接続してどうのこうのってのは出来るようになった。 Javaというより、RDBの勉強の方がいいと思うけどな。JavaとRDBのやり取りは、知らないフレームワークを介さないのであれば難しいわけではない。 >>757
>知らないフレームワークを介さないのであれば
学ばないでいつ知るんだよｗ
JDBCならともかくHibernateにしろSpring Data JPAにしろ
中身を把握するにはそれ相応の学習コストが必要 >>758
JDBC以外は全部、Java EEじゃないんですけど？
JDBCと言ってるのにいきなり謎のフレームワークを使えとはトレーナーとしてもありえない。 >>756
ありがとうございます。その本買ってみます。 >>759
トレーナーとして？
プロの次はトレーナー なんでそんなにプロにつっかかるん？
ふいんき悪くなるからやめたら？ SQL初心者です。
カラムをNULL許容型にするのは良くないと言った説明をいろんなサイトで見ます。
実際のところ、データが無い状態をNULLで表現する手法は、使わないほうが良いのでしょうか？
DBを使いまくっている専門家の人の意見をお聞かせください。 >>765
専門家じゃないけど
> カラムをNULL許容型にするのは良くないと言った説明をいろんなサイトで見ます。
必要ないなら非許容にするべき
理由は一番下のリンク先とかを読んでみて
> 実際のところ、データが無い状態をNULLで表現する手法は、使わないほうが良いのでしょうか？
そのケースなら俺は普通に使う
ただNULLの扱いは初心者にはちょっと直感に反するところがあるから注意が必要
https://codezine.jp/article/detail/532 >>765
リレーショナルデータベースではデータがない、値がないことを単にNULLと定義しているので、勘違いしないように。 自分はNULL活用してるけどな
0や空文字 と 未定義(未入力) とは意味合いが違う
フラグを別に設けるのも嫌だし
最近は言語側でも int? n; みたいなことが出来るようになって嬉しい >>770
NULLを検索するという設計がおかしい。 あれ、WHERE 項目 IS NULL ってインデックス効かないの？ NULLを検索する設計がおかしいとは思わんが
インデックスが効くかどうかはDBMSによる 「とある項目が未入力のものを探す」という風なのだが、わざわざフラグ立ててやるの？ NULLを検索が多発している時点で考え方がおかしい。 >>774
言わんとすることはわかるが、なんで未入力とわかっている状態を検索して再度、確認する設計なのか？ だから、「とある項目が未入力のものを探す」という風なのだが、わざわざフラグ立ててやるの？
机上じゃなくて現実の運用場面を経験したことないのか？ >>776
完全に入力が完了しないとコミットできない仕様(打ちかけを許容しない仕様)は
ちょっとユーザーフレンドリーじゃないと思うよ？ >>777
そもそもNOT NULLにしなくてはいけないと思い込んでいる初心者の話だろうが？ >>765
バグを生みやすいからNOT NULLにできるんならそうしたほうがいい
といっても全部排除するにはそれなりの手間がかかるので落とし所を決める必要がある
単にデータが無い状態を表現する場合じゃなく
データが「まだ」無い状態を表現する場合にNULLがよく使われる
簡単にデフォルト値が決められるようなものはNULL許容にしない >>778
入力完了済みのデータと入力途中のデータを一つのテーブルで管理するなら
完了済みかどうかの状態を管理するカラムを用意してそれを検索するんじゃないの？
特定のカラムがNULLだからXXという状態だと判断するって方法は極力避けたほうがいいと思うよ NULL許容はC#用語か。RDB用語で言ってくれ。不親切。 >>764
この流れを見れば
ふいんき悪くしてるのが誰かアホでも分かるよね？ この質問、例の人の自演だろ
あんま相手しないほうが良さそう nullはminとかmaxとかの集計関数で無視したい場合とか
更新が必要な項目で未更新状態の意味合いで使うな そういえばオラクルはキー項目でもnull許可できる糞仕様だったな
またオラクル使いか Oracleでもさすがに主キーにNULLは入らない
外部キーには入るがそれは別に普通のこと
それよりOracleは長さゼロの文字列とNULLが同じ意味になるという
糞仕様をいつまでも捨てられずにいることが問題 ま〜たこうやって、ボラクルの話になっていくのであった。 >>788
>nullはminとかmaxとかの集計関数で無視したい場合
条件で絞ればいいだけじゃないの？ 正規化してテーブルを増やしてデータの一貫性を保ちやすくするのは解ったんですが
テーブル増やしたらデータを追加するとき複雑になりませんか？
あっちのテーブルに日付情報入れて利用者ＩＤいれてこっちのテーブルに金額入れてとか混乱しそうな気がしますが NULL使わない人はデータが無い状態をどうやって表現するのですか？ NULLは必要だよ。
例えば日付型の生年月日があるとして、
NOT NULL なら default値はどうすんの？ 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への外部参照制約で表現できる NOT NULL縛りの是非はともかく、手間としては正規化とたいして違わない気がするが。
正規化を「いちいちそんな面倒なこと」と言う奴は少ないだろう。 null 可能列が10個あったら表が10個増えるのか w
まあ頑張れやとかしか言えない 単純に10個増えるとは限らないよ
派生関係でうまく処理できる場合もあるけど
任意項目があるたびに派生関係を作っていくのはあまり現実的ではないよね 思いつきでアホなこと言ったばかりに言い訳が苦しいなw >>800
で、外部結合して結局項目ｂがNULLになるのな ■ このスレッドは過去ログ倉庫に格納されています
