人気サイト様 最新記事

博士ちゃんねる ヘッドライン

レスの強調ウゼェー!というドクターへ

レス内の強調表示をOFFにする コチラをクリックして切り替えてください。設定は30日間Cookieに保存されます。
現在のステータス:強調有効

SQLだけがどうしてもなじめなくて苦手 @ [プログラマー板]


SQLだけがどうしてもなじめなくて苦手 @ [プログラマー板]
1: 仕様書無しさん 2018/04/17(火) 23:35:25.16 .net
業務でSQLを扱っているけどいまいち理解できないです。
INNER JOIN?何が「内側」なのか理解できない
LEFT OUTER JOIN?はぁ?何を基準に「左」なんだ?しかも「外側」…
抽出条件がWHEREだと?条件はIFかWHENだろうが!
直積とデカルト積の違いは?要するに「総当たり」なの?

こんな調子で業務に支障が出始めてます。
どうしたら理解できる?
4: 1 2018/04/17(火) 23:56:33.49 .net
しかもテーブル名がドイツ語を略したものだしよ!
5: 1 2018/04/17(火) 23:59:57.44 .net
1個のSQL文が数百行とかあってそれをメンテしてる
正直気持ち悪い
SQLを関数やメソッドのように考えてはいけないんだろうね。
7: 仕様書無しさん 2018/04/18(水) 07:15:05.72 .net
INNER JOINは使わないほうがいい。
エビデンス作業をホカの人に回せなくなるぞ。
管理人より:よくわからんひと向けの解説。「SQL」とは「Structured Query Language」の略で、リレーショナル・データベースへの問い合わせ用の言語。管理人の記憶が正しければ92年と98年に標準化されており、どのDBへも基本的には同じSQLでイケる!という建前になっています。
SQLの文法では、主に「SELECT(取得)」「UPDATE(更新)」「INSERT(追加)」「DELETE(削除)」の4つのステートメント(文)を駆使することとなります。当サイトはWPで動いてるから、カテゴリー名が「○○学」で終わらないエントリーのIDとタイトルとカテゴリー名を、日付の新しい順に上から5件取得する、簡単なSQLの例を以下に。
SELECT post.ID, post.post_title, term.name
	FROM wp_posts AS post
INNER JOIN wp_term_relationships AS rel
	ON rel.object_id = post.ID
INNER JOIN wp_term_taxonomy AS tax
	ON tax.term_taxonomy_id = rel.term_taxonomy_id
INNER JOIN wp_terms AS term
	ON term.term_id = tax.term_id
WHERE post.post_type = 'post'
	AND tax.taxonomy = 'category'
	AND term.name NOT LIKE '%学'
ORDER BY post.post_date DESC
LIMIT 5;
ID	post_title	name
17775	字幕派 VS 吹替派 VS 字幕すらいらない派 @ [映画一般・8mm板]	映画
17770	お前らはなんのために歴史を学ぶの? @ [世界史板]	世界史
17765	「レーダーが使えないから白兵戦になる」「は??」 @ [旧シャア専用板]	SF
17765	「レーダーが使えないから白兵戦になる」「は??」 @ [旧シャア専用板]	ロボット
17748	歴史上の人物を総動員して最強無敵の内閣を作るスレ @ [日本史板]	日本史
17765はカテゴリーが2個設定されてるので、2件出てきます。「DISTINCT」や、サブクエリーを駆使してどちらか1件だけ出すこともできます。「(CROSS) INNER JOIN」を使わなくても複数テーブル結合はできますが(FROM句に複数書く)、その場合ちゃんと結合条件つけないと総当たりになって凄まじい件数がヒットすることに。
件数だけ出したり、数値の集約計算もできるし、いくらでも複雑な条件でデータが取得できるので、SQLは使いこなせればとーっても便利!
»1さんがINNERとOUTERの違い、LEFT、RIGHT、CROSS、FULLの違いがわからないのは、これは数学の集合から拝借してる言葉だから。DBで使われる集合の概念くらいは図に書けば一発です。初学者向けの本には必ず書いてると思うし、別に難しくないですよ。
8: 仕様書無しさん 2018/04/18(水) 11:33:40.75 .net
>>1
一度DBエンジンを実装してみたらよくわかるようになる
10: 仕様書無しさん 2018/04/24(火) 08:37:46.77 .net
ノリでなんとかしてる
11: 仕様書無しさん 2018/04/25(水) 10:31:49.32 .net
クソみたいsqlでDBが遅いとか言ってくんなよ。
12: 仕様書無しさん 2018/04/25(水) 22:51:57.15 .net
>>1
頭悪いくせに理屈っぽそうだなw
ミック本読め
13: 仕様書無しさん 2018/05/03(木) 14:17:00.32 .net
ほんとうに難しいのはSQLそのものよりビジネスロジックだと思う
14: 仕様書無しさん 2018/05/05(土) 00:24:36.62 .net
難しいのは客の気まぐれを説き伏せることだろ
17: 仕様書無しさん 2018/07/24(火) 10:23:13.29 .net
良く出来るプログラマーほど苦手らしい
しかし大量のデータを扱ったり、インポートエクスポートやったりすると、なんかDBの良さが見えて来る。
自分で検索アルゴリズム作ったりするよりも速いし、そういうの見せられると自然と改宗する。
18: 仕様書無しさん 2018/07/26(木) 18:37:38.82 .net
いや、それはいいプログラマーじゃないだろ
19: 仕様書無しさん 2018/07/27(金) 23:59:21.66 .net
>>18
業務SEはDB好きなんだけど、オープンソースで発言力大きそうな人はDBエンジンがブラックボックスなのと、使い道が理解出来ない世界で生きてる感じがするわ。
KVSでなんとかなると言い切る
管理人より:ここでいう「KVS」は「Key-Value Structure」の略ではなかろうかと思います。「キー=値」となってるデータの連続てことです。
20: 仕様書無しさん 2018/07/28(土) 13:23:07.59 .net
プログラマでもなぜかSQLになると平気で明らかに重たい処理をデータベースに要求してくる。
どう処理されるのかまったく考えていないのだと思う。
21: 仕様書無しさん 2018/07/28(土) 13:31:54.62 .net
暗号化された文字列でテーブルフルスキャンを何回か行う設計
速度はしらない
24: 仕様書無しさん 2018/07/28(土) 16:33:55.12 .net
>>20
チューニング出来る奴ならフルスキャンは不味いと考えるが、件数はどうでもよく動いて納品出来たらあとシラネが普通だよ
23: 仕様書無しさん 2018/07/28(土) 16:20:44.84 .net
>>1はSQLの払い出し作業だけをやってんのか?
プログラマのようには見えんし数百行のSQLとかなんか俺の昔の職場と被るんだがまさか某携帯会社関連じゃないよな?
25: 仕様書無しさん 2018/07/29(日) 06:12:52.15 .net
>>23
高速化のためにJRの改札もそんなんだっけ
26: 仕様書無しさん 2018/07/29(日) 07:57:36.57 .net
今からでもSQLの文法変えてほしい
SELECTが射影でWhereが選択
SELECT前にあってWhereがSELECT前のグループにかかる

きがくるっとんのか
28: 仕様書無しさん 2018/07/29(日) 12:00:59.15 .net
自分でコンバータ作ればいいだけ。
セキュリティの観点からソースいじってsqlの文法変えるのはアリとは思うけど、使いづらいってのは経験不足なだけ
29: 仕様書無しさん 2018/07/29(日) 15:20:37.15 .net
コンバーターのぶん処理が余計になるし、メンテでそこ疑わなきゃいけいないし、引継ぎ者が誰も知らない文法覚えないといけないし、選択枝としてありえない

標準化委員会が新しいまともな文法のSQL作って敷衍するべき
32: 仕様書無しさん 2018/07/29(日) 15:56:49.61 .net
>>29
動的SQLという言葉は分かります?
大きなプロジェクトだとそういうの許されないんだけど。
LAMPの人には世界が違い過ぎるか
36: 仕様書無しさん 2018/07/30(月) 21:23:27.71 .net
>>32
クズみたいなツール有難がって使うような奴は巨大クソのメンテでもしてろ
37: 仕様書無しさん 2018/07/30(月) 22:18:40.58 .net
>>36
使いこなせないアピールはいいからw
38: 仕様書無しさん 2018/07/31(火) 06:57:53.74 .net
>>36
あのさ
お前が好きな文法でSQLもどきを作るだろ、コンバータにかけるだろ、それを本番のソースに埋め込めよって書いただけだぞ
セキュリティの面やチューニングは別人の専門家がやるという面からも、プログラム動作中に文字列を連結させてSQLを組み立てるはSQLをコンパイルする時間もかかるし禁止されてるプロジェクトもあるんだよってこと
万人月のプロジェクトの経験が無いと意味不明なのはわかるけど文句言うのはおよしなさいよ
39: 仕様書無しさん 2018/07/31(火) 07:22:05.37 .net
>>37
正直どうでも良いし絡んでも仕方ないんだけど、大手様謹製のクソツールに習熟したって大手のクソ仕事にしか役に立たないでしょ
素人が頑張って作ったようなツールよりも、OSSのプロダクトのほうがちゃんとしてるでしょ
俺は仕事選べるうちは、もうああいうのはやらん


>>38
長いよ
30: 仕様書無しさん 2018/07/29(日) 15:24:17.35 .net
コンバーターというかビルダー既にいろいろあるよ
34: 仕様書無しさん 2018/07/30(月) 19:17:26.38 .net
FROM
WHERE
SELECT


の順なのに、これを変えろと言うならANSIに言ってくれ。
35: 仕様書無しさん 2018/07/30(月) 20:15:19.95 .net
お前と俺違う世界線の人間なのか
俺の世界じゃSELECTが先に来てたような気がするんだが
管理人より:ウフフw
44: 仕様書無しさん 2018/08/03(金) 18:42:56.81 .net
「だけ」というか、なんでSQLを他の言語と混同するのかが解らない。
45: 仕様書無しさん 2018/08/03(金) 19:33:02.52 .net
>>44
DBから任意のデータを抽出するにはSQLを使わざるを得ないでしょ?
嫌ならCSVにでも出力させてから得意な言語で取ったり加工してロードすれば良い。
大量処理の場合、その方が早いこともあるけどな
46: 仕様書無しさん 2018/08/08(水) 00:42:15.35 .net
10行以上のSQLは見るの疲れるから止めてください!
47: 仕様書無しさん 2018/08/08(水) 02:26:29.96 .net
>>46
列ごとに1行で書く奴は確かに困るな。
でも結合やサブクエリを多用すると10行は超えることあるわ。
プログラム側でフェッチして書く方がプログラマは納得いくんだろうけど、そこは改宗したつもりでDBに委ねるのがSIerのプログラマだと思う
49: 仕様書無しさん 2018/08/12(日) 23:19:54.60 .net
>>47
はあ?いつもどんな単純なことしかしてないのか?
50: 仕様書無しさん 2018/08/12(日) 23:23:13.99 .net
SQLの構文は確かに失敗だった。しかしデファクトスタンダードになってしまったのだから仕方ない。

中途半端な英語の指示は日本人より英語圏の人の方が混乱してわかりにくいだろう。
途中まではよかったがSQLを拡張していく過程で開発者が面倒になってわかりづらい構文になってしまった。
51: 仕様書無しさん 2018/08/13(月) 20:27:06.71 .net
SQL苦手だと池袋のシスラボの研修でクビになるよ
52: 仕様書無しさん 2018/08/14(火) 12:34:00.95 .net
初心者プログラマにSQLを使わせないでDB操作をするためのライブラリとかクラスを作れ。
見たいな仕事は結構したよ。
俺が、DB操作のための新たな言語仕様をでっち上げて、それをSQLに変換するみたいな。
結局、SQLを直に書くが一番と分かった。
53: 仕様書無しさん 2018/08/14(火) 12:57:25.67 .net
>>52
既存のORM使えばいいじゃん
なぜそんな仕事を...
管理人より:「ORM」というのは「Object-Relational Mapping(O/R Mapping)」の略で、DBに対する操作をオブジェクト志向プログラミングと親和性を持たせたみたいな感じのやつ。SQL書かなくてよくなる。
上の方に出てる「コンバーター」とか「ビルダー」というのは、SQL文を直接書くとめんどくさいから、SQL書くためのヘルパーみたいなやつ。似てるけどちょっと違う。
54: 仕様書無しさん 2018/08/14(火) 13:13:02.03 .net
文法を統一してくれ。
同じメーカーの製品なのにaccessとsqlserverで違うのが一番納得できん。
55: 仕様書無しさん 2018/08/15(水) 08:07:32.52 .net
>>54
accessのjetは困るね。
まあ、おもちゃだから仕方がない。
mysqlを自分のpcに入れるしかないわ
56: 仕様書無しさん 2018/08/16(木) 01:29:58.94 .net
え、ちょっと待って
MySQLもおもちゃよ?
66: 仕様書無しさん 2018/08/19(日) 09:48:50.99 .net
>>56
おもちゃかどうかの基準は、クライアントサーバー方式かどうかだ
58: 仕様書無しさん 2018/08/16(木) 19:37:48.04 .net
煽るなよ。
oracleが正義なのはよく分かるけどさ、ボラクルになってからはもうポスグレかmysqlかsql serverの三択になってるよね。
俺の知識も化石化してる。
59: 仕様書無しさん 2018/08/18(土) 16:13:59.09 .net
Postgressだろ?
今のバージョンは性能いいらしいぞ?
管理人より:「Microsoft Access」はMS製の簡易DB。「SQL Server」はMS製でもうちょいちゃんとしたやつ。「Oracle」も同様に商用だけど、オラクル社製。「PostgresSQL」と「MySQL」はフリーのちゃんと(?)したやつ。「MySQL」も10年くらい前にオラクルに買収されてウンコになりました。
62: 仕様書無しさん 2018/08/18(土) 18:08:43.43 .net
設計ミスのカオス系システムだとDBに超絶負荷がかかるから、DB職人の神業で対応せざるを得なくなって、性能や機能が求められるのでOracleに頼りたくなる
でもDDDのリポジトリパターンにしたがって開発してると、BDの性能とか機能を追求したくなるような場面って思ったよりずっと少なくなるので、PostgreSQLやMySQLでなんの問題もない
63: 仕様書無しさん 2018/08/19(日) 00:48:31.60 .net
>>62
DDDと性能になんの関係があんだよ素人
リポジトリパターンって言いたいだけっしょ
72: 仕様書無しさん 2018/08/19(日) 13:07:44.68 .net
設計ミスのバカシステムしか作れないバカは、高機能高スペックのDBを使ってゴリ押しするしかない
まともな設計をしている常識人は、平凡な機能と平凡なスペックのDBでもなんの問題もなくやっていける

当たり前すぎるレス内容だから即座に内心同意して既読スルーする以外の選択肢などないと思っていたが、こんなアタリマエのことに突っかかってくる個性的な人も世の中にはいたんだね
76: 仕様書無しさん 2018/08/19(日) 21:45:15.39 .net
DBのスキルとPGのスキルは少し違うよね?
スーパープログラマはDBA目指さないし、意味不明にロックして泣きそうにデバッグ?するよかOracleでガンガンコードを書き進めたいよ
77: 仕様書無しさん 2018/08/19(日) 22:39:00.24 .net
>>76
典型的な素人
79: 仕様書無しさん 2018/08/20(月) 00:21:02.46 .net
>>76
いやいや、全部ひっくるめてエンジニアスキルでしょ。
判らなくて良いんだってのは、有り得ないから。
判らなくて恥ずかしいと思わないと。
80: 仕様書無しさん 2018/08/20(月) 02:33:40.61 .net
>>79
40代だとDB=Oracleだったので、当時のプラチナ持ちまでいたと思うけど時代は変わってしまったよ。仕方がないけどね
82: 仕様書無しさん 2018/08/22(水) 21:54:30.38 .net
始まったら思い出す
終わったらわすれる
(最初に戻る)

というわけで、わからるひとしかわからない、データベースとSQLにまつわるエトセトラ。

途中でちょっと出てきたけど、ここ10年くらいで様々なライブラリやフレームワークが充実して、SQLを書くこと自体が激減したとは思います。
データベースもいろいろ進歩してきて、そもそもリレーショナルじゃないやつも出てきました。「Mongo DB」みたいなSQLで問い合わせしないタイプのとかね。
昨今では巨大なデータをどう扱うか…ということに腐心してるとこあるから、RDBMS使っても、Elasticsearchに吐き出して全文検索…とかそゆのも多い。

今どきのナウでヤングなエンジニアは、そもそもSQLなぞ書いたことがないかも。
でもSQL書けないとなると、超複雑なことやろうとしたとき、書けるマはORMとかSQLビルダーとか使わずに直接クエリーを発行すればすむのですが、書けないマは右往左往することになります。

管理人は若いマによく聞かれる。
「ここからこれとこれのデータを取ってくるんですが、でもこれが入ってないやつとかもあって、どうしたらええっすかね…('A`)」みたいなことをです。彼らは信じられないことにLEFT JOINとかサブクエリーとか知らないのです。
ページをきっかり分ける関係上、プログラムで動的に余計な行を削って…ということはできず、複雑な条件を一発でDBから引っ張らないといけない、という局面ではSQLが書けないとわからんのですね。

管理人は北方謙三が「ソープへ行け!」というのと同じくらいの頻度で「サブクエリーを使え!」と言ってますが、「サブクエリーってなんですか?」「ORMでどうやってやるんですか?」とか言われるとガクッとくる。便利な道具を使うのはいいけど、使いこなせないなら意味ないです。
そゆのはサブクエリーでだいたい解決すんだ、覚えておきたまえ、若い諸君。(一部ウソがあります)

データベースはその性質上、データが増えるにしたがって応答時間も長くなっていきます。
禿げ上がるほど重たいクエリーをサックサク動かそうと思えば、ハードウェアのスペックを積む…というのがもっともお手軽ですが、お金もかかるしベンダーの餌食になるだけ。それは下策です。
インデックスの付け方を工夫するだけでビックリするほど軽くなるのですが、そんなDB職人もとんと減ってしまいました。
老兵はただ消え去るのみ、ですかねー。('A`)

スッキリわかる SQL 入門 ドリル215問付き! (スッキリシリーズ)
中山 清喬 飯田 理恵子
インプレス
売り上げランキング: 2,819



人気サイト様 最新記事

博士ちゃんねる ヘッドライン

    • ※1 : ドクター・ノオ・ネーム
    • 2018.9.20 21:43
    SQLくらいはなんとかかけるよっていうレベルなんだけどデスペは受かったわ
    • ※2 : ドクター・ノオ・ネーム
    • 2018.9.20 22:21
    SQLは書くのは簡単だが保守するのは非常に難しい。
    だから数百行のSQLメンテナンスは確かに辛い。
    VIEWとかストアドプロシージャをうまく使用して保守を簡単にすべき。
    • ※3 : ドクター・ノオ・ネーム
    • 2018.9.20 23:22
    UDBの経験者はおらんかのぉIBMのやつ
    • ※4 : ぼーっと読んだ感想
    • 2018.9.21 1:55
    ・そのうち新規テーブルを作れる人がいなくなりそう(汗 (ライブラリかツールか何かで「お手軽」に「効率のいい」設計と実装が自動化される未来がくるなら杞憂かな)

    ・100行ったってほとんど取り出すカラムの指定なんじゃなかろうか……条件句が100行だったら厄介か……それならそれでテーブル設計をしくじってるんじゃなかろうか……
    • >※4
      1個のステートメントが100行じゃなくて、超たくさんあるんじゃないですかねー。
      業務系システムだと月次処理とかそんなふうになってるの見たことあります。
      ストアドプロシジャもバリバリ使うやつで、メンテ大変そうですよ。
    • ※6 : ドクター・ノオ・ネーム
    • 2018.9.21 10:16
    データ量が多いと正規化した構成だと遅すぎて非正規化したな。
    SQLは1命令のプログラムだし、分割して考えていけば難しくないけど慣れなんだよな。

    使うDBによって命令が違ったり、Oracleだとスキーマー、Mysqlならdatabaseとか同じ意味なのに名前が違うのが辛い。
    • ※7 : ドクター・ノオ・ネーム
    • 2018.9.21 12:47
    何が難しいのかが理解できんわ……
    • ※8 : ドクター・ノオ・ネーム
    • 2018.9.21 15:17
    ORMってホント効率悪過ぎて
    これSELECT-FROM-WHEREの基本構文しか書けない様な素人が
    これがあれば便利とか思って作ったんだろうなって思ってしまう
      • ※14 : ドクター・ノオ・ネーム
      • 2018.9.26 21:13
      >※8
      もともとは単純なSQLを毎回書くのがバカらしいから普及したので
      ただ単に普及した後の要望による機能追加に伴い、
      無理やりな実装する人が増えただけだと思いますけどね。
    • ※9 : ドクター・ノオ・ネーム
    • 2018.9.21 22:41
    欲しい結果から逆算ができればあとは集合演算に強いかどうかだけなんだけど、日本の教育的に不足してるから、どっちかで引っかかるんだよな
    前者は解から問いを作る訓練、後者は遠山啓さんの無限と連続を読むとかかな

    ORM操るのはアプリケーションエンジニアでは必須のスキルで、場合によって方言を使った必要な最適化仕掛けるのがここ数年求められてる対応
    大抵のORMライブラリでインデックス貼れるしサブクエリだって打てる
    トランザクションやマイグレーションはORMの方が大抵は楽だし
    生SQL書いた方が早いかもと思うときはあるけど、書けるライブラリのが多いし
    • ※10 : ドクター・ノオ・ネーム
    • 2018.9.22 14:43
    100行のSQLってたまに聞くけど、
    DB構造ミスったか、取り出してからプログラムで回すべきものを端折った結果だろうな。
    • ※11 : ドクター・ノオ・ネーム
    • 2018.9.23 0:38
    CakePHP使いまくっててSQL忘れた時期あった
    • ※12 : ドクター・ノオ・ネーム
    • 2018.9.23 13:18
    プログラミングの最適化と、SQLの最適化は勝手が違う気がする
    どこが違うと言われると困るし、そんなにDB使わないから間違ってるかもだけど
    • ※13 : ドクター・ノオ・ネーム
    • 2018.9.25 20:58
    インデックス=牽引 といっても、もう分厚い辞書を使わないから、若い人達には分からないのかも。
    頭文字でデータまとめてしまえば、全件調べる必要がなくなる。そんな感じの仕組みが インデックス というもの。
    そして インデックス を使って参照するデータを減らすのがSQLの最適化=速度向上

    紙の辞書を使わなくなったから、DBというものが想像できなくなってるのかもね。
    DBが想像できないから、SQLが理解できないとか?
    • ※15 : ドクター・ノオ・ネーム
    • 2018.9.28 23:37
    ログに「おせえよなんとかしろよ」って出ているクエリにEXPLAINつけてシコシコ最適化した思い出。
    • ※16 : ドクター・ノオ・ネーム
    • 2018.9.29 0:31
    SQLは慣れ。慣れれば快速、それまで鈍行。
    テーブルは正規化必須。正規化してから非正規化の導入検討。
    サーバ負荷は偏らせない。選択、射影、集合はDB、編集はAP。
    よゐこのお約束。
  1. トラックバックはまだありません。


コメ欄での議論はおおいにけっこうですが、当サイトではドクター同士の罵り合いは禁止となっております。反論する際には、相手の意見・人格を尊重し、どうぞ冷静に。