SQLer 生島勘富 のブログ

RDB・SQLの話題を中心に情報発信をしています。

SQL概論

DBオブジェクトの命名法と主キー

DBオブジェクトについて、Rails などのようにどうしても「外側から管理したい」と考える人たちは、言語側の命名法で処理したいと考えるようですが、DB側から見ると非常に使いにくいです。 そのため、弊社では以下のような命名法で用途に応じて別名を提供して…

SQLと手続き型言語 - JOIN を手続き型で書いてみる

SQL と手続き型言語(オブジェクト指向言語)は最終的には同じです。 今回は、JOIN を手続き型言語(Javaっぽく)書いてみます。 目次 目次 オプティマイズについて 2つの表をJOINしたSQL 単純なネスティッドループ(NESTED LOOP) インデックスを使ったネ…

ほとんどのエンジニアは「Staticオジサン」よりひどい3

前回の続き。 目次 目次 正解はこうなる イメージはこうなる つまりこれはバグ!! 「Staticオジサン」はStatic決め打ち ちなみにWordPressはこんな変換をしています

ほとんどのエンジニアは「Staticオジサン」よりひどい2

前回の続きです。 目次 目次 まずは間違いの例 もう少しマシな人の例 まずは間違いの例 たぶん、何も考えてない人は以下のようになったと思います。 基本構文を分かってない。どうしようもないですね。 もう少しマシな人の例 工夫はしたけれど、残念! 正解…

ほとんどのエンジニアは「Staticオジサン」よりひどい1

「Staticオジサン」が炎上して10年ほど経ちましたが、当時、私が指摘した通りほとんどのエンジニアは「Staticオジサン」よりひどく、10年経っても改善してないどころか、更にひどくなっているのではないかと思います。 目次 目次 自分はできると思う人は例題…

第14・15回 SQL Server 2019勉強会より - はてなブログに引っ越し記念

はてなのブログに引っ越しました。 思い出したようにブログを再開したいと思います。 目次 目次 Twitterは議論に向かない。 私の主張 SQLの方が息が長いからロジックをSQLへ寄せた方が良い SQLが分かりにくいという常識とは? 教育からやり直すべき 嫌いな人…

「艦これ」から、ソーシャル系のサーバ構成を考える

私は、ソーシャル系とは縁遠い仕事ばっかりしているのですが、そういう依頼も若干増えてきたので話題になっている「艦これ」をお盆にやってみた。 残念ながら、「艦これ」の魅力は分からなかった。しかし、ミッションを用意されると、「クリアーしたい」とい…

SQL文を組み立てるには?SQLが書ける様になるには?

SQL文ができない人は、どこまでも文法で考えようとしている。 私が、SQLに違和感を感じずに理解することができたのは、文法を気にしてなかったからで、私の勉強法というか、どうやって習得してきたのかを整理してみました。 例えば IN と EXISTS の違い カラ…

RDBMSを使う以上、SQLを使いこなさなければいけない

何度も何度も言ってるけれど、「処理を分割した方がDBサーバの負荷が減る」と感じるのは勘違い。 http://d.hatena.ne.jp/Sikushima/20110809/ http://d.hatena.ne.jp/Sikushima/20110810/ http://d.hatena.ne.jp/Sikushima/20110811/ http://d.hatena.ne.jp/…

SQL的(集合的)考え方と、ループ(手続き型)の考え方3

問題を少し変更 問題)部品在庫から、作成可能な製品の情報をとる。 ※本来はマスタテーブルと組み合わすべきですが、ツールの関係上2テーブルしか同時に表示出来ないので名称で結合する形になります。 SQLで考えるなら という風に考えます。 言い換える 『在…

SQL的(集合的)考え方と、ループ(手続き型)の考え方2

もう一度問題 問題)部品在庫から、作成可能な製品名をとる。 ※本来はマスタテーブルと組み合わすべきですが、ツールの関係上2テーブルしか同時に表示出来ないので名称で結合する形になります。 SQLで考えるなら 答えは SELECT 製品名 FROM 部品表 INNER JOI…

SQL的(集合的)考え方と、ループ(手続き型)の考え方1

前回、勉強会に参加したときに感じたことの続き。 みんなはどう考えているか? この問題は正答率が低かった。答えを見たら「あぁ〜」ってなるレベルですが、なかなか、出てこないようです。 問題)部品在庫から、作成可能な製品名をとる。 ※本来はマスタテー…

久しぶりに更新

昨日、SQLWorldの「みんなでSQLを書いてみよう」というハンズオンの企画の勉強会に参加した。 最初にお知らせ 次回の企画のために、「実務で困っているSQL」を募集するそうです。 「こんなのSQLで出来るの?」という問題があれば、コメントやメール info@g1s…

MySQL Cluster: NoSQL について

MySQLの Cluster: NoSQL がなかなか良さそうです。 私自身は、それを使う様な案件に恵まれてないので使わないとは思うけれど、チャンスがあれば使ってみたい。所謂、NoSQLは半端すぎて使いにくい。NoSQLという新たなモノを作るよりも、RDBMS が NoSQL を飲み…

なぜごり押しなのか3 -- 初級シスアドレベルは超えるべき。

なぜ、煽って【詐欺師】なんて言うかというと、これは初級シスアドで出題された問題です。 初級シスアドの午後の問題を見れば分かりますが、他が満点でもSQLができなければ合格できない比重になっています。それでも、初級シスアドなんて、就職氷河期を乗り…

なぜごり押しなのか2 -- 詐欺師になるな。

世の中には本当に【詐欺師】のような技術者が詐欺的なものを作って飯を食っています。 例えば、以下、ぱっと見て何をやっているSQLか理解できるでしょうか。 ■ テーブル構造 ■SQL SELECT 資格取得履歴表.社員番号,COUNT(*) FROM 資格取得履歴表,社員表 WHE…

なぜごり押しなのか。

私は妥協点をほとんど出しません。なぜそんなに頑ななのか?その答えは単純です。 SQLを使うか、使わないかでは以下の様なグラフになります。 しかし、多くの人達は以下の様なイメージ上で、議論を行っています。 皆さんがある程度許せるという妥協点は赤丸…

効率の山は複数回訪れる。

正規化の効率を考えてみる。 正規化は基本的な技術ですが、COBOLから抜けきれていないと正規化すると遅くなると感じる様になる。 これはおそらく私もだろうと思うけれど、効率をグラフ化して最初に訪れた山が最高と感じるものです。それはつまり、落ち始めた…

無意識を意識する。

そもそも、私はプログラムを習ったことがないから、一般的な専門学校などでやっている様な講義は知らないしやりようがない。私が講師をやると厳しすぎるので、新人教育を担当することはないのですけれど……。 新人を相手するときに、私が最初に説明するのは「…

OLAP(分析)関数について -- 完成

前回の続きです。やっと完成です。 ざっくりとした考え方(毎回) GROUP BY は集約するので、結果が(集約キーを出力すれば)一意になる。つまり、出力される結果が一意になるまで集約される。 しかし、OLAP(分析)関数は、SELECTされた結果を区切って処理…

OLAP(分析)関数について -- OLAP(分析)関数はSELECT句で並び替え

前回の続きです。やっとOLAP(分析)関数までたどり着きました。 ざっくりとした考え方(毎回) GROUP BY は集約するので、結果が(集約キーを出力すれば)一意になる。つまり、出力される結果が一意になるまで集約される。 しかし、OLAP(分析)関数は、SEL…

OLAP(分析)関数について -- その前にサブクエリーで処理

前回の続きです。 ざっくりとした考え方(毎回) GROUP BY は集約するので、結果が(集約キーを出力すれば)一意になる。つまり、出力される結果が一意になるまで集約される。 しかし、OLAP(分析)関数は、SELECTされた結果を区切って処理する。そのため、…

OLAP(分析)関数について -- SQLはテストファースト指向

OLAP(分析)関数は考え方としては、SQLの他の構文よりも手続き型言語と差が小さい。 考え方ではなく、文法から入る人にとってはとんでもない違いに感じるかも知れませんが、答えは同じなのですから違いはないのです。 長くなるので数回に分けて書こうと思う…

RDBMSをタバコ屋さんで説明

勉強会に参加さてもらい、次の勉強会でお話しすることになったので宣伝です。 前の勉強会では以下の様な実験が話題になっていました。http://www.doaplus.com/html/bun/bun03_20051101.html まあ、極めて当たり前の結果です。 5000万件が500万件になるという…

SQLのイメージと他の言語のイメージ3

SQLで処理するイメージと、他の言語で処理するイメージを書いてきましたが、必ずしもSQLで処理することがベストと言えないこともあります。例えば、ガンダムのジオラマが最終目標だったとして、パフォーマンスや要望と、あるいは、プログラマの能力などを考…

データ量とインデックスについて

新人研修の季節ですね。 以前、インデックスについてカラオケ本をイメージして考えましょうと書きましたが、新人研修などでは、あまり難しいことを考えずイメージを持つことが非常に重要です。 是非、新人研修の前後で読んでいただければと思います。 もちろ…

COBOLerからの脱却2

ウォーターフォールのままでも切り口を変えればシステム開発は大きく変わる。アジャイル開発にも移行できます。 ↓ 逆に、現状のままでアジャイル開発に移行すれば、大きな規模の案件ではカウボーイコーディングにしかならないです。ウォーターフォールで設計…

COBOLer からの脱却

COBOLer の DNA IPA の調査では、2009年の段階で96%がウォーターフォールを採用しているそうです。 http://sec.ipa.go.jp/press/20100330a.html まさに、ウォーターフォールは一つの文化として確実に定着しています。ウォーターフォールには COBOLer の DNA…

SQLの担当は分けるべき

おそらくSQLほど差の大きなスキルはない。 SQLはスキル差が非常に大きい。 本当にできない人はどうしようもなくできない。 SQLは仕様書であってプログラムではないのですが、その感覚がつかめないと習得は非常に難しい。 オプティマイザという人間に比べると…

リモコンは指で押せ!

SQLは大昔からあるメタプログラミングなのですが、メタプログラミングと呼ばれない理由は、自動生成されたコードが見えないからでしょうか。ベンダーにすればそれを見せてしまえばRDBMSの中身を見せているのと同じですし、見せる必要もないのでしょう。その…