SQL質疑応答スレ 17問目 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
このスレは
「こういうことをやりたいんだけどSQLでどう書くの？」
「こういうSQLを書いたんだけどうまく動きません＞＜」
などの質問を受け付けるスレです。
SQLという言語はISOによって標準化されていますが
この標準を100%実装したDBMSは存在せず、
また、DBMSによっては標準でない独自の構文が
追加されていることもあります。
質問するときはDBMS名を必ず付記してください。
【質問テンプレ】
・DBMS名とバージョン
・テーブルデータ
・欲しい結果
・説明
前スレ：
SQL質疑応答スレ 16問目
http://echo.2ch.net/test/read.cgi/db/1447160858/ >>689
そんな疑問持ったことなかったなw何も考えずにPK_hageとかしてたけどw
おまえセンスいいかもw >>689
制約には名前をつけることができるが
主キー制約の場合はテーブル毎に一個しか持てないので
名前をつけようがつけまいが利便性は特に変わらない
（ので、主キー制約自体に名前をつけることは通常ない） >>694
名前の無い主キーを作成出来るのですか？ 主キーの名前って言えば普通は列名のこと
PK制約の名前とは別だよ
CREATE TABLE Persons (
ID int NOT NULL PRIMARY KEY,
…
↑こう書けばDBMSで規定されてる命名ルール使ってPK制約名が付けられる >>696
「主キー制約」と「PRIMARY KEY 制約」は別物と言う意味に解釈できるのですが、
それで良いのでしょうか？ >>697
それは日本語で言うか英語で言うかの違いで同じ 制約に名前をつけなかった場合、OracleならSYS_○○、
DB2ならSQL○○など、システムが勝手につける名前がつく >>697
主キー列(カラム)は、そのテーブルで主キー制約がある列(カラム)のこと。
単に主キーというひとが多いからよくない。
主キー列はただの列名。主キー制約名は主キー制約名。
主キー制約に名前をつけなくてRDBMSが自動的に名前をつけるが、プロなら管理の都合上、ちゃんと名前をつける。 CREATE TABLE Persons (
…
PRIMARY KEY (ID)
…
こう書いても同じでDBが自動で名前を付けてくれる >>697
主キー制約 = PRIMARY KEY 制約 だよ。(主キー=PRIMARY KEY)
ひとつの列が主キーであるなら、その列の名前＝主キーの名前、という理解でよい
主キーの名前の付け方にはいろいろな流儀があるが、
SQLを利用するフレームワーク (例えば Ruby on Rails)との関係で
id という名前にすることが最近は多い
>>690 が書いているように、pk_hage みたいな人も多い
(「サロゲートキー」で検索するといろいろ出てくるはず) >>704
PK_hageはプライマリキー制約の名前で列名じゃないよ >>702 が書いているように、
RDBMSに主キーの値を自動的に割り振らせたいようなときにも
列名を id とする たぶん主キー制約名で一番多い命名は、PK_(テーブル名)。 >>705
制約名にすることが多いけど、列名にする人もいる
(質問者はそのあたりがごっちゃになっているっぽいけど) 制約名と列名を混同している人がいるな
複合キーの場合どうすると思ってるんだ？ ただ"ID"という名前の列を作って主キー項目にするのは、たいしたデータベースを必要としていない人の習慣。 主キー列名、主キー制約名、インデックス名がちゃんと説明できるレベルの人は、この板にはほとんどいない。 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許可できる糞仕様だったな
またオラクル使いか ■ このスレッドは過去ログ倉庫に格納されています
