SQL質疑応答スレ 17問目 [無断転載禁止]©2ch.net
レス数が900を超えています。1000を超えると表示できなくなるよ。
このスレは
「こういうことをやりたいんだけどSQLでどう書くの？」
「こういうSQLを書いたんだけどうまく動きません＞＜」
などの質問を受け付けるスレです。
SQLという言語はISOによって標準化されていますが
この標準を100%実装したDBMSは存在せず、
また、DBMSによっては標準でない独自の構文が
追加されていることもあります。
質問するときはDBMS名を必ず付記してください。
【質問テンプレ】
・DBMS名とバージョン
・テーブルデータ
・欲しい結果
・説明
前スレ：
SQL質疑応答スレ 16問目
http://echo.2ch.net/test/read.cgi/db/1447160858/ 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
彼はオブシェクト指向とごっちゃになっているのだろう。 価格というテーブルがあって
商品：外部参照(商品マスタの主キーを参照)
適用開始：日付型
適用終了：日付型
区分：0:標準 1:販売
通貨記号：USD/JPY・・・
単価：通貨型
という感じに定義されていて
標準価格や販売価格が実はテーブルじゃなくて、
価格テーブルを元にしたビューだった
という風なら理解できるぞい >>859
価格というテーブルには、
標準価格か販売価格のどちらかしか
入らなくなりませんか？ user_id派は昔ながらのリレーショナルモデル、id派はERモデルの発想だろう。
そのへん区別できてない人も多いけどな。 >>849-850
爺は早めにくたばれよ w
>>856
テーブル名書かないの？
単一テーブルしか扱わない時はいいけど複数テーブル使ってる時にテーブル名を書かないとかその方がどうかしてると思うけど
>>858
はあ？
ひょっとして
ドットで繋いでる⇒オブジェクト指向
とでも思ってるのかよ w
全然関係ないだろ >>859
そのケースで標準価格と販売価格を一つのテーブルで管理するメリットって何？ >>861
リレーショナルモデルとERモデルの違いについて、簡単にで良いので説明してくれ >>862
>複数テーブル使ってる時にテーブル名を書かないとかその方がどうかしてる
複数テーブル使うときにテーブル名で「修飾」しないで済むようにしましょう、ってのが根本にあるわけで
そのためにjoinにusingとかあるんだが
まあなかなか現実的にはそうすると項目名がやたら冗長になったりするから適当なとこで妥協するんだけどね
個人的な感覚では
標準単価なんかは妥協する必要のない範疇
更新日時なんかは妥協して問題のない範疇
IDなんかが議論の分かれるとこなんでよく話題にされる
まあ、宗教論だよ >>865
>標準単価なんかは妥協する必要のない範疇
>更新日時なんかは妥協して問題のない範疇
この線引を明文化して規約にしないと
同じデータベース内でブレた命名基準が使われて
一番使いにくい物ができあがる 更新日時は文字通り誰が解釈しても一意になりそう
標準単価は、何を指すのかな？
商品なら、定価だったり、希望小売価格だったり
賃金なら、時間給か日給か月給？
その現場毎に決めるんだろうな >>852に書いてるようなデータベース上のレコード最終更新日時と
ドメインで意味がある更新日時(サイト更新日時とかスレ更新日時とか)だと解釈違ってくるよね
システム的な事情で「スレ」テーブルのデータを更新した場合でも
ユーザーが目にするスレ更新日時は更新されない事も有り得る >>864
先に属性があって、それらの間に何らかの関係が存在するときにそれをリレーション(テーブル)として
表現するのがリレーショナルモデル。属性はテーブル固有ではないのでそれ自身識別できる名前に
することが多い。
問題領域からエンティティを抽出してそれに含まれる属性を記述するのがERモデル。基本的に
属性はそのエンティティ固有のものだから他のエンティティと属性の名前が重複しても気にしない。
ただしERモデルをRDBに落とし込む際は他エンティティとの関係を表す参照フィールドが必要になる
場合があるが、これはそのエンティティに属するものとは言えないため必ずしも一貫性はない。 c1,c2,...,c10と言う10個のカラムがあって、その中のどこかにkeywordが有るか判定するなら
c1 like %keyword% or c2 like ...
みたいに10個並べればいいですよね。
ではkeyword1とkeyword2が有るかどうか判定するなら同じくずらずらと条件を並べるしか無いですか？
もっとスマートに簡潔に書く方法は有りますか? >>871
なるほど。
実際の開発の現場でもそういう手法を使うんですか？
ずらずら並べる方法と連結する方法とでは、どっちが検索が速いでしょうか？ LIKE検索の時点で似たり寄ったりだし
どうしても早くしたいなら全文検索エンジンとか使え
http://www.clear-code.com/blog/2015/5/25.html >>870
クエリの見た目のキレイさだけならJOINの条件でLIKEを使う方法もある
パフォーマンスは一般的に良くない
外部結合使った例
SELECT *
FROM target t
LEFT JOIN keyword k1 ON t.c1 LIKE k1.col
LEFT JOIN keyword k2 ON t.c2 LIKE k2.col
LEFT JOIN keyword k3 ON t.c2 LIKE k3.col
WHERE k1.col IS NOT NULL
OR k2.col IS NOT NULL
OR k3.col IS NOT NULL ;
内部結合使う場合は結合条件をORでつないでカラムを並べるかUNIONするか >>870
そんなSQLが必要なテーブルがおそろしいわ。 c1...c10が等価で交換可能なのだとしたらそもそも第1正規形じゃないから実際の開発の現場で見かけるのは稀。
等価じゃないのに「その中のどこか」なんて問い合わせするのも稀。
「実際の開発の現場」じゃまず現れないレアケースなんで「スマートに」なんて期待するな。 >>875,876
正しい設計のデータベースにも普通にありふれたテーブルですよ
経験不足なんですねあなた達 自分が面倒見ているサイトで
ユーザーにアイテム検索させる時に
このようなSQL書いてるな そんな面倒なのを非手続き型SQLでやろうとする発想がすごい。 >>876
バカ設計はどこにでもある。稀じゃない。 >>876
例えば社員情報を氏名、役職、所属、電話番号、社員番号の一部で検索するとか普通にあるけど？ >>874
すみません、このコードを試してみたのですが外部結合など
初めてやるので実行するとエラーしました（SQL ServerとMySQL）。
このサンプルコードは、完全なSQL文ですか？
それとも概略を示したものですか？ >>884
SQLがいいか悪いかを無視しても少なくともLIKEの前にANDがない。 シンタックスすら覚束ないのに善し悪しを語りたがるバカｗ ああ、間違ってるな。
ただあのSQLのkeywordとはなんだろうな。 >>884
何をもって完全とするかは君にしかわからないけど
SQL ServerでもMySQLでも問題なく動くよ
外部結合もやったことなくて何のエラーが出たかも分からないようなら
自分の今のレベルを素直に受け入れてLIKEでベタ書きするのがスマートだと思うよ >>874
ウンコード・マニアがSQLに対応していたらかなりいい点が貰えそう なんだかよくわからないけどとりあえず煽ってみるウンコバカw このスレは想像、想定で回答する人間が多くて驚く。エスパーなのか？ 案外おっさんがいるんだな。
エスパー魔美を連想するとは。 >>895
クエリ書くのはSQLのほうが簡単
MongoDBでクエリ書くのもそんな難しいわけじゃないけど
JavaScriptやmap/reduceの基本理解は必須 簡単か難しいかは比較対象によるからね
SQLと比較すれば難しいし手間もかかる
SQLは全くの素人でも3日程度の研修受ければ
自分が欲しい結果を取得できるレベルにはすぐなれるが
JavaScriptだとそうはいかない SELECT cust_id, sum(amount)
FROM orders
WHERE status = 'A'
GROUP BY cust_id
上のSQLがmap/reduceだと↓ココにあるような関数になる
https://docs.mongodb.com/manual/aggregation/#map-reduce
他にもMongoでのクエリとSQLと比較してるドキュメントがたくさんあるから自分で見るといいと思う
https://docs.mongodb.com/manual/reference/sql-aggregation-comparison/#examples >>898
3日でSQLマスターするってスゲえな
どうやるんですか？ >>902
マスターは言い過ぎ
文法を理解して自分が欲しい結果を取得するためのクエリが書けるようになるレベルな
ちゃんとした会社の研修コースを受ければいい
本で言えばスッキリのレベルなら2日コース
ゼロからはじめるのレベルなら3日コースが標準 なぜsqlもmongodbも初心者レベルなのに答えようとするのか select ...
where カラム名 like '%'
みたいなwhere条件を追加した場合、このwhere条件が無い場合に比べて
検索時間が遅くなったりしますか？ そりゃDBMSのオプティマイザの賢さ次第だな。試してみればいい。 >>905
やってみなはれ。
やらなわからしまへんで。
鳥井信治郎 で、遅くなったとして「じゃ条件つけるのやーめた」なんて出来るのか？ クエリ組み立てる側で手間かければできないことないだろ。
もともと意味のない条件をつけるのがおかしいわけで。 >>905
ただSQLだけで遅いの速いいうのはナンセンス。 どんなSQLだけだったら遅いの速いのいうのはナンセンスじゃないんだこれ？ 質問させてください
番号 住所
(number) (address)
1 東京
2 大阪
3 東京
住所でGROUP BYして番号順に並べたい
さらに住所の合計を取得したい
SELECT *,SUM(address) FROM table_addr GROUP BY address ORDER BY number DESC;
これだと番号順に並びません。どうしたらいいでしょうか？よろしくお願いします。 番号順って、小さい順にしたいの？それとも大きい順？ >>913
レスありがとうございます
一応DESCですがASCでも構いません >>914
SELECT MAX(number) AS number, address, COUNT(address) AS kensu
FROM table_addr GROUP BY address ORDER BY MAX(number) DESC; 自作自演なのか？
なんでsumがカウントの間違いだとわかるのか？ まあ住所の合計って意味わからんからな
よく気づいたと思うけど GROUP BY とORDER BYって同時にできるの？ >>919
グループ化したものを並び替えることはできる。
並び替えたものをグループ化しても意味がない。 >>920
へえー
じゃあグループ化してないカラムを並び替えすることは出来る？ SQLってcasesensitivitieじゃないんですよね？コマンドを小文字で書いても良いですか？
いちいちcapslock雄の面倒 SQLって英単語の羅列で構造がぱっと見わかりにくいから、昔は予約語だけ大文字にするとかあったけど、
最近はエディタでハイライト(色分け)できるのが普通だから全部小文字でも全然問題ないな。 小文字でも普通にオッケーなんですか
sqlite のクエリを書くのにpythonのIDE使ってるんでsintax highlightは効かないので見にくいかもしれない
一長一短すね 使ったことあるのは oracle, SQL-Server, PostgreSQL, sqlite3, MySQL だけだけど、全部小文字でも問題なかったな 一行に詰め込もうとかしなければ小文字でも読めるやろ 英文(って言うかアルファベット)の大文字の綴りなんて、まず読みにくいだろ？ 大昔はコンソールから大文字しか打てなかった時代があった COBOLも小文字
というかcase insensitiveやで COBOLは今は大文字小文字混じりだよ
FORTRANもね
SQLは特定の場所以外大文字小文字関係ない
内部では処理系によって大文字か小文字に変換して処理する 板違いかもしれませんが、hirdb詳しい方いませんか？いたらhirdbのストアドが使い易いか教えて下さい。使ってるのみたことなくて… >>938
ネットに公表されているマニュアルを見たのか？
ストアドは標準SQLだから標準SQLとかけ離れていることはない。 >>940
みました。標準的にみえるけど、あまり使われてないDBMSだから落とし穴がないかこわくて。そもそも自分がそんなにストアド使ったことないから判断しかねるのもあります。
それと、過去ログにはトリガー設定して自動で動くようにはできない？？との記述もあって… レス数が900を超えています。1000を超えると表示できなくなるよ。
