SQL質疑応答スレ 17問目 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
このスレは
「こういうことをやりたいんだけどSQLでどう書くの？」
「こういうSQLを書いたんだけどうまく動きません＞＜」
などの質問を受け付けるスレです。
SQLという言語はISOによって標準化されていますが
この標準を100%実装したDBMSは存在せず、
また、DBMSによっては標準でない独自の構文が
追加されていることもあります。
質問するときはDBMS名を必ず付記してください。
【質問テンプレ】
・DBMS名とバージョン
・テーブルデータ
・欲しい結果
・説明
前スレ：
SQL質疑応答スレ 16問目
http://echo.2ch.net/test/read.cgi/db/1447160858/ >>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になるのな >>810
ならなかったらそもそも>>796への答にはならんだろ そもそも「データが無い状態」という情報をどうしても記録しておかなければいけない状況ってのはそうそうない
そのシステムの性質にもよるけど 閉世界が前提だから、「データがある」状態だけ記録しておけばそれが存在しなければ「無い」だと思うが。
明示的に「無い」ことを記録しているわけじゃないだろう。 >>814
いやそういう禅問答的な屁理屈を言われても「その通りですね」としか言えんけどw
何か反論したい事でもあるの？ >>812
外部結合の結果とはいえ、デーが無い場合はNULLになるってことだ
直接テーブルに入れてないとは言えNULL使ってるわけだから>>796の回答足り得てないと思うけど? >>815
データが無いことを記録する必要があるかどうかという問い自体がナンセンスということ。 >>812
それってb列に直接null入れるとのたいして違わなくね？ >>816
NOT NULLにしたとしても外部結合したらNULL発生しうるじゃん
そうすると>>796への回答足り得ないの？ 派生関係はNULLを使わないために導入するものじゃないから話が噛み合わないのかもね >>817
ん？つまりnot null制約自体の存在を否定したいのか？ 「データが無いことを記録する」手段が唯一NULL許可フィールドのみなのであれば
NOT NULL制約と関係なくはないのかもしれんが、まぁ、関係ないよな。 >>822
いや論じる事がナンセンスなんだろ？
その事と関係あるとかないとか唯一とか関係ないよね？
お前は何を言いたいの？ 質問者の>>796、とりあえずどうにか話の方向をどうにかしてくれよ。
nullの話は簡単に結論が出るようなもんじゃないんで、いつまでも続けられても鬱陶しいだけなんだ 人と違ったことを言わないと気がすまない人っているね
俺は俺はってw こんな過疎スレで話が続いても誰も困らんだろ
それより質問者を含めスレ読んでるやつが
多くの選択肢を知ることができるほうが意義があると思うぞ 禅問答は傍で見ているとうざいが、かといってテーブル10個作るのは面倒だなんてレベルの話ばっかりでもなぁ。 >>823
「必要性があるとないとにかかわらず、意図的に「記録」するまでもなく、
「データが無い状態」というのはデータベース上のデータ自体で表現される
ものだから、>>813で書いている言明はそもそも意味がない」
本来なら「その通りですね」で終わってた話。 >>827
無意味なテーブル作るのなんか、たとえ1個でも願い下げだわ
作るのが面倒とか以前の問題 >>819
>>796は、NULL使わない場合を想定した質問だぞ
データがない場合はNULLですだと、そもそもの質問の前提が成り立ってない
>>820
>NULL使わない人はデータが無い状態をどうやって表現するのですか？
に対する答えとして派生関係を出してきたはずだが
>>828
意図的にデータがない状態を記録するのに、NULLを使う手法はありかなしかって話をしてたんだと思うけど
そんな要件は現実的にあり得ないってならまあその意見もわからんではないが
実際のシステム設計じゃままある要件なんだがな
いい加減スレ違いなのは確かだし、これ以上は設計スレあたりで ちょっとした疑問なんだが、
ユーザーと所属するグループ、チームを表すテーブルを作る場合、カラムの命名についてはどっちが主流なんだい？
パターン1
テーブル:group_table
カラム:id,name
テーブル:team_table
カラム:id,name
テーブル:user_table
カラム:id,name,group_id,team_id
結合:
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
パターン2
テーブル:group_table
カラム:group_id,group_name
テーブル:team_table
カラム:team_id,team_name
テーブル:user_table
カラム:user_id,user_name,group_id,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句の書き方が気にくわないとか色々あるだろうけど、一先ず置いといて、
命名として、どっちなんだろうなと思って >>836
JOINの結果NULLが現れるから回答になってないってのはさすが屁理屈が過ぎるだろう。
>>796の前まではフィールドのNOT NULL制約について話していたわけだし、>>796も
それを踏まえた質問ととらえるのが自然。 >>833
どっちが主流かは知らんけど俺はパターン1 >>833
プライマリキーとそれ以外のカラムでは扱いが違う
プライマリキー以外のカラムにテーブル名を単純なプリフィクスとして使う人は少ない
プライマリキーについてはDBよりの人はuser_id派が多めな印象
アプリよりの人はid派が多い印象(言語やフレームワークにもよるが)
個人的にはuser_id派 >>835
>>836
サンクス
後だしで悪いが、
idはpk、
pk以外のカラムについては、name以外の話はなしでおなしゃす。
(nameはこうするとかのみで)
話が膨らんでしまうと発散して意味を成さなくなるので。
ちなみに自分はパターン2派。
関連がが分かりやすいので。
けれども、パターン1でも、テーブル名から予測可能だし、そもそも関連については外部キーで定義しろよと思うので、思想の話かなと。
職場でも、両派いるので、時流はどちらなのか知りたい次第です id派は基本的に全テーブルのプライマリキーをidという名前にする前提なので
単に命名の問題じゃなく設計に関わってくる問題
この辺読んで両方の意見を参考にするといいと思う
https://softwareengineering.stackexchange.com/questions/114728/
idじゃなくbug_idにしようぜってのがSQLアンチパターンにも出てくる >>838
サンクス
参考も読ませてもらうよ。
そんなあなたは、設計も命名も自由にできるとして、どっちにするの？ >>833
状況によるんでどっちが主流とか無いんじゃね
ＯＲマッパーとか前提で、IDやSQLをあまり意識しないでいいなら１
生SQL扱うなら、本来の考え方からいけば２だろうな SQL Serverの管理ビューは１で
Oracleのデータディクショナリは２だな
他のDBMSはどうだろう 論理レベルで複合キーやナチュラルキーのテーブルを
物理レベルでどう扱いたいかが重要な分岐点 >>844
同じものには同じ名前をつける
違うものには違う名前をつける
これが原則
たとえば標準単価と販売単価を、同じ単価と言う項目名で定義するのはよろしくないだろ
ここ設計スレじゃないしこれ以上はどっか別のスレでよろしく >>846
何で列名だけで判断してるんだ？
標準価格.単価 と 販売価格.単価 が同じものに見えるなら病院に行った方がいい そんな紛らわしいこと実務でやる奴いたら、とっちめられるぞ >>846
何をもって同じとするのか
何をもって違うとするのかの基準が違うから
id派とuser_id派に分かれるんだよね
例えば各テーブルに内部的な管理用としてレコードの更新日時を記録する場合
最終更新日時とかの名前でどのテーブルも同じカラム名でも別におかしくない
レコードの更新日時という意味で同じだから
id派の考えはその延長 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
) >>852
無理矢理すぎる理屈だな。
登録・更新者、登録・更新日時の項目は、結合項目として使用するなどどいう話は、あなたの中でもないだろうに。 そうかなあ
テーブル名もカラム名の属性を表してるわけで
テーブル名をテキトーにつけてなけりゃ
情報の一部だべ >標準価格.単価 と 販売価格.単価
テーブル名まで書くんだったら、最初から
>標準価格 と 販売価格
で良いんでは >>855
テーブルの論理名はエンティティ名といって、適当に名前をつけていたら、混乱するだけでよいことはない。 >>856
彼はオブシェクト指向とごっちゃになっているのだろう。 ■ このスレッドは過去ログ倉庫に格納されています
