SQLer 生島勘富 のブログ

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

2010-06-01から1ヶ月間の記事一覧

SQLは文法からやっちゃダメ

SQLができる人はたくさんいます。しかし、ほとんどの人は文法から勉強し、文法と実経験からSQLのスキルをつけていったのじゃないかと思う。 同じくオブジェクト指向言語などの手続き型言語も、文法から覚えた人がほとんどじゃないかな。 私の知る限り、手続…

INとEXISTSの違い

INとEXISTSは違います。 BETWEENと、不等号の組合わせなど、等価になる記述法はあるのですけれど、INとEXISTSは基本的に同じ結果を返すことが可能ですが、意味は違います。 この違いが分かるにはインデックスを理解する必要がありますので、まずは、インデッ…

インデックスについて

インデックスが分かってない人が非常に多い。 現実にあった例で、60カラムあるテーブルに、前から3つずつの複合インデックスを20個作るとか、30カラムを1つの複合インデックスにするとか、意味が分かっていない人が非常に多くいます。 ※ 詳しい人へ。ここで…

LIKE検索は使ったらダメな場合もある - 全文検索について

SQLのLIKE検索は非常に便利です。しかし、データ量によっては使ってはいけません。 例えば、 WHERE 備考 LIKE '%大阪%' とすれば備考欄に'大阪'が含まれているレコードをすべて取得することが可能ですが、当然、インデックスは使えません。必ずテーブルをフ…

オブジェクト指向言語で処理すると工数が掛かる

数回に分けて複雑なSQLををストアドプロシージャ(ファンクション)を使ってデチューンしてみました。 整理すると ■1.OLAP関数を使って一括処理するパターン ■2.誤差配賦額をファンクションを使って計算するパターン ■3.誤差配賦額をファンクション内でル…

ストアドプロシージャでループ処理 - 複雑なSQLをデチューンしてみよう

前回作成したスカラー値関数(fn誤差配賦消費税額)をループして処理する形にのものを作成しましたが、今回はメインのプロシージャを修正することにします。 都合、4種類書いてみましたが、全角の利用でイライラしながらも全部で6時間ぐらいでした。やってみ…

SQLでユーザ関数を活用2 - 複雑なSQLをデチューンしてみよう

元のストアドプロシージャをデチューンしていきます。 前回作成したスカラー値関数(fn誤差配賦消費税額)をループして処理する形に修正します。長くなっていますが、この方が読みやすいかも知れません。 ※ もちろん、実際には、明細単位、納品書単位、請求…

SQLでユーザ関数を活用 - 複雑なSQLをデチューンしてみよう

元のSQLを今回は、OLAP関数が使えないという条件でデチューンしてみます。ソースコードはSQLServerで記述しています。 まずはベースになるSQLを考える。 元のSQLが複雑と感じるか簡単と感じるかは人それぞれですが、ベースの部分は極めて単純です。重要な部…

デチューンの前にダミーのストアドプロシージャ

前回、複雑なSQLをデチューンするという話を書きましたが、弊社ではまずはダミーのストアドプロシージャを作るということを推奨していますので、ダミーのストアドプロシージャから作成します。 出力する内容が以下になるので、その通りのダミービューを作り…

複雑なSQLをデチューンしてみよう

初級編の続きは、 インデックスについて(カラオケ本で考えよう) IN、EXISTSと違いについて などなどを予定しているのですが、twitter で何度かつぶやいたもののまとめなので、ログなどと差は大きくはありません。 ちょっと訳あって、初級編をお休みして、…

前提が抜ける

私のコラムとか、ブログとか、前提が抜けるとよく批判される。 半分はわざとで半分は無意識です(苦笑) 「わざと」というのは、例えば、「SQLで書くと可読性が下がる」とか、「複雑なSQLを書くべきでない」ということが、一般的に言われていることを百も承…

ストアドプロシージャでできないと思うのはOracleのせい

ストアドプロシージャでできない。できるわけがない。というのは、Oracleのストアドプロシージャ(ファンクション)でSELECT系の処理がどうしても難しいからです。 ストアドプロシージャで弊社で使っているスタブとしてのストアドプロシージャ(ファンクショ…

JOINとWHERE句に結合条件

SQLは標準言語で、ISOやANSI、JISなどで規格が決められています。 前回はFROM句とWHERE句について書きましたが、結合条件はFROM句に書いています。これはANSI 推奨の書き方です。ISO では、元々、WHERE句に書くように規定されていて、Oracleは ISO に準拠し…

FROM句とWHERE句

SQLが分からないという人は、文法を理解しようとしてしまっていることが多い。ですが、私は文法解説は極力やりません。SQLは全体を把握してイメージでとらえないとまっとうに書けないからです。 SQLのSELECTは次の順で処理されます。 FROM・WHERE句の中のサ…

オブジェクト指向言語ならNoSQLで、RDBMSを使うならサービス指向アーキテクチャで

図1 オブジェクト指向言語での一般的な処理 この図は、オブジェクト指向言語としていますが、構造としてはCOBOL技術者がオープンの世界に流れてきて確立した文化からなんの変化もない。非常にいびつで、SQLとオブジェクト指向言語の言語のスパゲッティプログ…

表現の自由と規制2 - 炎上したコラムについて

いろんな方から励ましのコメントやツイートや、トラックバックまで頂きました。 どうもありがとうございます。 結局、私の文章は、SQLのスキルが高い人、SQLのスキルを上げたい人には好意的に読んで貰える。しかし、元々スキルが高い人にスキルを上げるべき…

ストアドプロシージャでシステムを構築するとDBサーバの負荷が増えるか

結論から書くとストアドプロシージャでシステムを構築するとDBサーバの負荷は減ります。WEBシステムと仮定してDBサーバとAPサーバの関係で書きますが、C/Sも同じになるので、C/Sで考える人は、APサーバをクライアントと置き換えて読んでください。 その理由…

NoSQLとSQLについて

NoSQL(Not Only SQL)とは、SQLを使わないKVS(Key Value Store)などを指しますが、最近流行のキーワードです。今日はNoSQLについて。 SQLは英語であり仕様書である SQLは英語であり仕様書である。と書いてきました。 SQLは、プログラム(アルゴリズム)を…

スタブ用のエクセルを販売します

ビジネスロジックはストアドプロシージャに入れるべきと書いてきましたが、現在のバージョンでもOracleのストアドプロシージャ(ファンクション)は非常に書きにくいです。 SELECT系のストアドプロシージャ(ファンクション)の書きやすさは SQLServerr > D…

日本のホワイトカラーの生産性を上げるには3

日本のホワイトカラーの生産性が低い大きな原因の一つに、システム会社の生産性が著しく低いことがあると考えています。 SEはいわゆる3K職といわれますが、仕様変更を防げたら無茶な長時間労働をする必要はないのです。しかし、システム会社が仕様変更を防…

日本のホワイトカラーの生産性を上げるには2

日本のホワイトカラーの生産性を上げるには、データベース設計をプログラミングの後に行うべき、そのためにはビジネスロジックをストアドプロシージャに入れる必要がある。ということを前回書きました。 今回は、具体的にどうしてストアドプロシージャが効率…

日本のホワイトカラーの生産性を上げるには1

日本のホワイトカラーの生産性が世界的に低いらしい。なぜ、日本のホワイトカラーの生産性が世界的に低いのか。いろんな理由があると思いますが、システム開発会社である私の考えは、ホワイトカラーの生産性を上げるという使命を持った我々システム会社が十…

SQLとはどんな言語か - SQLは仕様書です

SQLとはどんな言語かなぜ多くの人が違和感を持つかというと、多くの人が、「プログラミング言語とは手続き型言語である」(オブジェクト指向言語も広義の手続き型言語)という思い込みがあるからでしょう。 手続き型言語の中には 非構造化言語(FORTRANなど…

表現の自由と規制

最初からこのネタか(苦笑) 最近、表現の自由について考えています。 メディアはエロ漫画の規制についてゆゆしき問題と言います。 しかし、そんなものは十分な規制をすべきでしょう。大人なら当たり前に分かる話。そんな当たり前の話が通用しなくなってこの…