データベースとSQLの業務スキルレベル　判別表　（５段階）

リレーショナル・データベースを利用したシステム開発の，簡易スキルチェックのための調査表。印刷用。

データベース・エンジニアのレベルを測定する。

レベルは，０から４までの５段階。

（０）非エンジニア

（１）初学者（入門書を学習してゆく段階）

（２）ノーマル（基礎的な知識があり，ある程度の動くものを作れるようになった段階）

（３）中級者（開発プロジェクトで１人月としてカウントできる水準）

（４）上級者（メインPG/メンターとして，主設計を任せられる水準）

Webアプリのプロジェクト開始時に作業振り分けをするにあたって，新規メンバ全員にこれを渡して回答してもらうという用途を想定。

なお，開発上のスキルをチェックする事が主眼なので，DBAとしての技量はあまり考慮しない。

下記で「自分に当てはまる項目が最も多いレベルが，自分の属するレベルである」とする。

※ただし，中級者の項目に書いてある事は，上級者にも当てはまる場合がある。

ちなみに，こういうチェックリストがなぜ必要かというと，

偽って「SQLできます！」と自称するエンジニアのほとんどは，簡単なSELECT文しか書けないからである。

＝＝＝＝　紙で渡す場合は，ここから下を印刷　＝＝＝＝

◆◆　データベースを使った開発に関するアンケート　◆◆

自分に当てはまる項目に○を，当てはまらないものに×をつけて下さい。

10分程度で記入を終えて下さい。

※もし，わからない用語があったら，その用語に下線を引いて，？マークを書いてください。

※「DB製品」という語は，オープンソースを含むRDBMSを指すものとします。

（０）非エンジニア

DBといえば，最初にドラゴンボールの事を思い浮かべる。

dbといえば，最初にデシベルの事を思い浮かべる。

内心，データベースやSQLが「怖い」と思っている。なので，代わりにテキストファイルにデータを格納しようとする。

「SQLが実行される」と聞くと，すごく重い処理が走るというイメージが浮かぶ。なので，思考パターンとして，DBアクセスをできるだけ避けようとする。

（１）初学者（入門書を学習してゆく段階）

簡単なSELECT文であれば，そらで書ける。それ以外の文は，何も見ないで正しく書ける自信はない。

ネット上で見つかるサンプルSQLコードにところどころ手を加える事によってであれば，ある程度のDB操作は自分ひとりで実現できる。

CRUDという言葉の意味を理解している。CRUD図（CRUDマトリクス）を読み書きできる。

（テーブルやカラムの）「論理名」と「物理名」の違いを理解している。

「論理削除」と「物理削除」の違いを理解している。

主キー（プライマリーキー）という言葉の意味を説明できる。

DDLとDMLとはそれぞれ何か理解している。

WHERE句の中で，「WHERE カラム名 = NULL」のような間違った書き方をしてしまい，あとから書き直すという事がよくある。
- もしくは，この書き方のどこが間違っているのかわからない。

ORDER BY, LIMIT, OFFSETを使って正確に絞込みができる。

VARCHARやTIMESTAMPなど，DB内に存在するデータ型を普通に知っている。

M・V・Cの３層構造について知っている。また，DAOとは何かわかっていて，それに相当するものをコーディングしたことがある。

「ここのUPDATE処理は，代わりにデリートインサートで実装してね。」と言われた場合，どのようなSQL文をコーディングすればよいのかわかっている。

「マスタデータ」とは何かわかっている。それを格納するテーブルがアプリケーション中でどういう性質を持つのか，理解している。

複数のテーブルにまたがった検索を行ないたい場合は，複数のSQL文の実行結果を手作業でマージしたり，繰り返しSQLを発行したりする。そういった余分の作業が発生することに対して，疑問を感じない。

JOINを使いこなせない。　なので，
- テーブルを適切に分割して設計することができない。
- 同一のデータがあちこちのテーブルに分散して保管されていても，別に危機感を感じはしない。
- 「正規化」についてよく知らない。
- データを１カラム内にカンマ区切りで格納するのが好きだ。

トランザクションを利用しない。コミットやロールバックに関する意識を持っていない。

DB構築用のSQLファイルやテーブル定義書やER図といった物すべてを，別個に手動でメンテナンスしている。
- つまり，そういった複数のドキュメント間で情報が自動的に同期されるような仕組みを導入していない。

DB製品に最初からついてくる管理ツール類（例えば，PostgreSQLであればpsqlやpgAdmin）だけを使って，DBにアクセスしている。理由は，他のツールの使い方を知らないから。
- 複数のDB製品に対して汎用的にアクセスできるようなツールを使った事がない。

WHERE句で条件を指定する際，似たような条件式を，（条件1）or（条件2）or（条件3）or ・・・といった具合に大量に並べるのは普通のことだと思う。

GROUP BYとHAVINGを正確に組み合わせて使う方法が，ちゃんとわかってはいない。WHEREとHAVINGの違いをわかりやすく説明したりできない。

DBにおける「インデックス」の意味や効用をよく知らない。

「ujis」とは具体的にどういう文字コードの事を指すのか，わからない。

ODBCについて知らない。JDBCは聞いたことがあるが，自分ひとりでその設定をすることはできない。

接続文字列という言葉を知らない。通常TCP/IPを経由してDBにアクセスするという事もよくわかっていない。
- あるいは，ふだんDB接続はプリコンパイラ（Pro*Cなど）に任せきりなので，２層構成（クライアント/サーバー・モデル）のアプリケーションしかわからない。

DBから取り出したデータを，アプリ側でソートしたり件数の絞込みをしたりする事に違和感を感じない。つまり，アプリケーション中でDBが果たすべき役割をよく理解していない。

使ったことのあるDB製品は１つだけである。DB製品の名称を５つ以上言ってみろ，と言われた場合，知らないので言えない。

（２）ノーマル（基礎的な知識があり，ある程度の動くものを作れるようになった段階）

INSERT文，UPDATE文，DELETE文を全てそらで書くことができる。

WHERE句の中で，IN, BETWEEN，EXISTS，IS, LIKE，正規表現マッチを使った条件指定ができる。

楽観ロックと悲観ロックの違いを説明できる。

各種ALTER文で何ができるのかほとんど把握している。が，そらでは書けない。

「SELECT *」と書いてはいけない，とされている理由を知っている。

JOINを普通に使える。
- つまり，「複数テーブルにまたがったデータ取得操作」を，まともに行なうことができる。
- テーブルとはリレーションと共に使うものである，という事がわかっている。
- LEFT OUTER JOIN，RIGHT OUTER JOIN，INNER JOIN の違いを図示して説明できる。

サブクエリ（副問い合わせ）やUNIONを普通に使える。
- つまり，「複数クエリにまたがったデータ取得操作」を，まともに行なうことができる。
- これらの操作のパフォーマンスの違いについては，よくわからない。

トランザクションを必要に応じて適切に利用できる。
- つまり，「業務アプリ開発時のデータ操作」をまともに行なうことができる。
- オートコミットについても知っている。
- ACID特性についても知っている。が，全てそらで言うことはできない。
- トランザクションの分離レベルについては，よくわからない。

GROUP BY や集計関数を，HAVING 句と正確に組み合わせて使える。
- つまり，「サブグループを使ったデータ集計操作」を，まともに行なうことができる。集計関数は SUM, COUNT, MAX，AVGなど。

NULL値を別の値に置き換える関数の関数名を知っている。

「タプル」や「フィールド」が何を指すか，理解している。

複数のテーブルを束ねるための上位概念としての「スキーマ」という言葉を知っている。

ER図を普通に読み書きできる。特定のエンティティ間の関係（カーディナリティ）を，自分で考えて識別できる。（たとえば１対多，多対多など）

オブジェクト指向の言語で開発する場合にはO/Rマッピングが必要になるということを理解しており，説明できる。永続化という語を知っており，Hibernate や NHibernate のようなORMツールを使った経験がある。

正規化されたテーブルを設計できる。
- あえて正規化を崩すべき事態がどうして必要になるのかについては，よくわからない。

DBにおける「インデックス」や「複合インデックス」の意味を理解しており，そのメリットとデメリットを説明したり，必要に応じて作成したりできる。
- インデックスを作成すべきかどうかを数値的に判断する方法はわからない。

「カーソルを経由してrowをfetchする」とはどういう事か理解している。

ODBC設定やJDBC設定を，自分ひとりで行なえる。必要なドライバを自分で探し出してインストール・設定できる。

任意のDB製品の接続文字列について，自分ひとりで調べて設定できる。TCP/IPを経由してどのようにアプリがDBに接続しているのか説明できる。

DBに接続できない時，クライアント側の接続設定・DBサーバ側の接続許可設定・DB内部のPRIVILEGESなどを，自力で手際よく順番に調べ，DB接続できるように環境を調整できる。

テーブルのデータをCSVに出力したり，CSVのデータをテーブルにインポートしたりするための構文を使える。

データベースのバックアップやリストアを実行した経験がある。

php○○Adminシリーズについて知っており，自分ひとりでセットアップして活用できる。

相関サブクエリや自己相関サブクエリを，使ったり説明したりできる。
- それに関係したパフォーマンスの相違や改善方法については，よくわからない。

デッドロックを防止するためにはアプリケーション側でどのように処理設計すればよいかを説明できる。

RDBの「制約（CONSTRAINT）」には例えばどんなタイプがあるか，３つ以上言える。それらの利用経験がある。

少なくとも２種類以上のDB製品を利用して開発した経験があり，その機能的な差異について説明できる。

数千件規模のデータをRDBで扱った経験がある。

資格「応用情報技術者」を保有している。

SELECT / INSERT / UPDATE / DELETE を含めた全てのSQL文を，常に適切にインデントして記述している。

SQL文中に，適切にコメントを記述できる。

GRANT・REVOKE文などを使い，必要に応じてグループやユーザやその権限類を管理できる。

DBを利用するアプリを開発することはできるが，トリガやストアドプロシージャについてはよく知らず，その必要性がわからない。

アプリが動的にカラムを追加したり，動的にテーブル構造を変化させたりするのがシステム設計上よくない，という事を理解していない。

「SELECT FOR UPDATE」文を使ったことがない。その効用もよくは知らない。

（３）中級者（開発プロジェクトで１人月としてカウントできる水準）

システムの要件に応じて，あえて正規化を崩すべき局面が判断でき，柔軟にテーブル設計できる。また一方で，正規化を崩す際に生じ得るリスクを正確に把握しており，トリガ等を使ってそれらの問題を解決する方法を説明できる。

行ロックやテーブルロックを使ってアプリを構築できる。
- デッドロックが起こりうる状況のサンプルも示せる。
- 実装すべき処理内容に応じて，ロックのスコープを自分ひとりで判断できる。
- しかし，ロックエスカレーションを経験したことはない。

自己相関サブクエリや自己結合を使いこなせる。それらが必要になる状況のサンプルを示せる。

テーブル中でバイナリデータ(BLOB)を直接扱った経験がある。それらのデータをファイルシステム上に保存しないことのメリットについて説明できる。

Rails系フレームワーク（CakePHPなどを含む）のモデル層で，ActiveRecord系のライブラリを使ってコーディングした経験がある。
- システム開発時にSQLを直接記述するのは時代遅れである，という点を理解している。
- ActiveRecordが，DB操作のための生産性の高いDSLである，という点も理解している。
- Associationを辿る際には，ちゃんとメソッドチェインで済ませている。

ORM利用時には，DBを抽象化するために，DB製品ベンダに固有の機能の利用を極力避けるべきであるという点を理解している。

DB製品の名称を５・６個以上そらで言うことができ，それらの差異について簡潔に論じることができる。

現実世界をモデリングし，自信を持ってデータベースの論理設計を行なう事ができる。

アプリケーションの機能要件を考慮し，データベースの物理設計を行なう事ができる。
- しかし，非機能要件までは手が回らない。

数十万〜数百万件以上の規模のデータをRDBで扱った経験がある。

独自のSQL関数や集計関数を定義し利用できる。

シーケンスを日常的に利用している。
- しかし，「シーケンスを使えば必ず，重複しない連続した番号を得られる。」と思いこんでいる。
- または，「Webアプリケーション中で，重複しない連続した番号を得るためのロジックを，自前で実装することができるだろう。」と思っている。

DBにおける「ドメイン定義」や「コード定義」が何を意味するのか知っており，それらのドキュメントを作成できる。

SQLインジェクションの実行方法と対策方法を知っている。
- 単純な，クオートのサニタイズし忘れで発生する，ごく基本的な攻撃。
- クライアントとDBサーバ間での文字コードの違いや，日本語処理対応不足に基づく，高度な攻撃。
- セカンドオーダーSQLインジェクション。

重複レコードの扱い方を理解している。つまり，
- 「テーブル内の重複レコードを検出するようなSQL」を書くことができ，
- 「検索結果から重複レコードを排除して表示するようなSQL」を書くことができ，
- テーブル内に重複レコードが登録されないようにDB側で防止する事ができる。

トランザクションの４つの分離レベルについて知っている。つまり，トランザクション間での排他制御をするための方法を知っている。それらを知らない場合に発生する問題（ファントムリードやダーティーリード）のサンプルを挙げられる。

INやEXISTSを使ったサブクエリは，JOINで書き換えられるということを理解している。そのサンプルを挙げられる。

DB構築用のSQLファイルやテーブル定義書やER図といった物すべてを，別個に手動でメンテナンスしていない。どれか一つのリソースから他の物を自動生成している。

NULLにまつわる問題を理解しているので，テーブル設計時には可能な限りNOT NULL制約をかける。NOT NULL制約をかけない場合に具体的にどのようなミスが発生するか例を挙げられる。

Transact-SQLもしくはPL/SQL系の言語を利用して，ストアドプロシージャやトリガイベントを扱える。それらがなぜ必要になるのか，どうしてアプリ側の処理でまかなうことができないのか，システム設計上の理由を説明できる。

プリペアド・クエリを使える。

Ruby on Railsのマイグレーションのような物を使って，スキーマ構築操作を複数のスクリプトに分割してバージョン管理した経験がある。

システムテーブルやINFORMATION SCHEMAを有効活用している。（コマンドではなく）SQL文によって，あるデータベース内のテーブル一覧を表示させたり，あるテーブル内のカラム一覧を表示させたりすることができる。

オプティマイザに対してSQL文の実行計画を問い合わせることができ，その出力結果の読み方もわかっている。その出力結果に応じて，インデックスを作成すべきか否かを判定することができる。

アプリケーションのビューのデータ列挙部分のUI設計において「ページング」とは何か理解しており，それを実装できる。それを実装する上でパフォーマンス上の問題を引き起こさないようにするために，適切なSQL文をコーディングできる。

金銭の授受が絡むアプリケーション（例えば会計システムや注文管理）のDBを，少なくとも一度扱った事がある。

DBのアーキテクチャにおいて，データファイルとトランザクションログ（REDOログ・ジャーナルログもしくはWALログ）が分離されている目的が分かる。媒体障害時に，いざとなったらログを使ってロールフォワードの復旧をする，という覚悟が既にできている。

コミットの実行と，チェックポイントの実行の違いを分かりやすく説明できる。

データベース上のデータを外部に保管してドキュメントとして扱うためには，スプレッドシート形式で扱うのが最適である，ということを理解しており，実践している。例えば，DBに投入すべきサンプルデータやマスタデータをExcel上で表形式で保存しており，VBAマクロでDMLを生成したりしている。DMLを直接手書きでメンテするなどという愚行は犯さない。

カラムやテーブルの物理名を命名する際に，日本語のローマ字表記を使うべきではない，という点を理解している。もし日本語のローマ字表記を使うと表記の揺れが発生してしまう，という点を例を挙げて説明できる。

資格「オラクルマスター・ブロンズ」を保有している。

（４）上級者（メインPG/メンターとして，主設計を任せられる水準）

資格「DBスペシャリスト」を保有している。

「オラクルマスター・シルバー」以上の資格を有している。

開発対象となるアプリケーションの帳票を，一目見さえすれば，必要なテーブル構成は一瞬で思い浮かぶ。

複数のDB製品の中から，アプリケーションの要件に応じた最適なDB製品を選択・導入でき，その件に関して説明責任を果たせる。

少なくとも１つのDB製品について，その設定パラメータを知り尽くしている。

パフォーマンスやセキュリティ等，アプリケーションの非機能要件を考慮して，自信を持ってデータベースの物理設計を行える。

バッチ処理とオンライン処理におけるトランザクションの設計上のポイントの相違を理解している。

DBサーバのディスクスペースの見積もりに慣れている。

DBサーバのレプリケーション（クラスタリング）や分散トランザクションの使用経験がある。あるいは，十分な納得できる理由の下で今までそれを避けてきたという経緯があり，どうして特定のRAID構成を採用しなかったのか解説できる。

ロックエスカレーションに遭遇・対処した経験がある。

大量（数十万件規模）のテストデータを，効率よく作成するノウハウを持っている。

memcachedやtmpfsを媒介させたり，ヒープテーブルを使うことによって，DBの動作を高速化できる。それらを導入した場合に生じ得る問題点を把握しており，適切に導入検討やチューニングを実施できる。

特定のDB製品について，共有ロックと排他ロックが，それぞれ発生・解除されるタイミングがいつなのかを説明できる。

MVCC（マルチバージョニング）方式についてよく知っている。そのトランザクション分離レベルが何なのかを説明できる。ロック方式と比べた場合のメリットも説明できる。

DBのリバースエンジニアリングは，ORMを利用する上で，ごく普通の手順だと思う。

SQLの構文解析アルゴリズムを把握している。なので，エイリアスが使えない場合とはどのようなものか知っている。

DBそのものを単独でお客様に提供するのではなく，データウェアハウスのような「ソリューション」として積極的に提供できる。

RDBMSに発生しうる障害のパターンと対処法を体系的に把握しているので，予期せぬトラブルに対する不安がない。

本番環境におけるアプリケーション運用中に，DBサーバの容量が一杯になるという事態に遭遇・対処した経験がある。または，それに準じた何らかのDB運用上のトラブルに遭遇・対処した経験がある。

会計/金融システムのDB設計のために必要な知識を持っており，実践できる。

データモデルが，時系列の（動的な）観点で過不足なく要求を満たしていることを検証するために，データフローダイアグラムやCRUD分析を適宜有効に利用できる。

OSSの各種DB製品の最新バージョンのトレンドについて知っている。

（オープンソースではない）商用DB製品の利用経験がある（特にOracle）。そして，それらの価格体系をある程度知っており，導入コストを概算できる。

３値論理に基づくブール代数の演算に抵抗を感じない。

「スキーマ」の上位概念としての「カタログ」や「クラスタ」という語を理解している。

DB上で四則演算（例えば金額の乗算や除算）をする際，桁精度や数値計算上の誤差を考慮している。

OSSのDB製品を，ソースからコンパイルしてインストールした経験がある。

特定のDB製品に関わる全てのデーモン（orサービス）のプロセスを把握している。

「手続き型言語」と「問い合わせ言語」の間にある，根本的な概念の相違について語れる。

DBサーバに施すべきセキュリティ対策について一通りの事を把握している。

何らかのデータマイニングや統計処理機能の実装経験がある。

ファンクションポイント法において，とくにデータファンクションの見積もり方法を知っている。

雑誌「WEB+DB PRESS」や「Software Design」などを欠かさず通読している。あるいは，それらを読む必要がないレベルに到達している。

SQLのみならず，WQL，HQL，LINQ等の派生技術にも通じている。

集合論および関係代数に通じており，それらの用語（例えば「デカルト積」など）を一通り人に説明できる。それらの概念を使ってデータベースを論じる事ができる。

「関数従属」という語を使って３つの正規形について論じる事ができる。それらの用語を使ってテーブルの設計方針を話し合う事ができる。

B木やビットマップインデックス等のインデックス実装方式と各方式の特色についてよく知っており，必要ならそういったアルゴリズムを自前で実装できる。

マージJOINやハッシュJOINなど，JOINの内部処理方式についてよく知っており，それらがパフォーマンスに及ぼす影響を説明できる。

トランザクションモニタを利用したOLTP監視体制の導入経験がある。

２相コミットとは何か，図を書いて説明できる。

分散システムの場合，RDBでいうACID特性がどのように確保しづらくなるか説明できる。その代替モデルとしてのBASE特性やCAP定理を知っている。

NoSQLとRDBMSを対比し，それぞれのメリット・デメリットを説明できる。

＝＝＝＝　ここまでを印刷　＝＝＝＝

ここから先は，各レベルごとに，フォローアップ用のURLを掲載する。

（０）非エンジニア

http://ja.wikipedia.org/wiki/DB

（１）初学者（入門書を学習してゆく段階）

「楽観ロック」と「悲観ロック」の違いを知らない人は入門者である，という事項の出典：

プログラマーの力量を見極める--面接官になったら尋ねるべき質問実例集
http://japan.zdnet.com/sp/10things/20...

知識の網羅的な学習：

イチからはじめる　SQL レファレンス
http://www.i2kt.com/dbms/sqlref/index...

DB製品別の関数一覧

各種処理：

スレッド: COALESCEの読み方って？
http://www.oracle.co.jp/forum/thread....

「コアレス」

SELECTでワイルドカードを使ってはいけない、必ず列名を列挙して書かなくてはならない、という常識
http://q.hatena.ne.jp/1231235330

Oracle Database Net Services 管理者ガイド / 通信レイヤーの理解
http://download.oracle.com/docs/cd/E1...

Oracleのクライアント・サーバ型アプリケーションに対して，TCP/IPおよびOSI参照モデルがどのように当てはまるか（図4-2 OSI通信レイヤー）

Oracle Netの主要な機能は、クライアント・アプリケーションとOracle Databaseサーバー間の接続を確立して維持すること（Session層に該当）

ドキュメント：

ER図から，Webアプリを自動生成しよう　（A5SQL Mk2 + CakePHPを連携させる）
http://language-and-engineering.hatenablog.jp/entry/20090131/p1

発注者が確認しやすいようにCRUD図をアレンジする
http://itpro.nikkeibp.co.jp/article/C...

ツール

phpMyAdminと，その類似品
http://ja.wikipedia.org/wiki/PhpMyAdm...

（２）ノーマル（基礎的な知識があり，ある程度の動くものを作れるようになった段階）

各種処理について

「相関サブクエリ」とは何かを理解して，複雑なSQLでも読めるようになろう
http://language-and-engineering.hatenablog.jp/entry/20101108/p1

PREPARE文と，PL/pgSQL の入門　　（PostgreSQLで「動的に」SQLを実行するために，プリペアド・クエリやストアドファンクションを定義しよう）
http://language-and-engineering.hatenablog.jp/entry/20110218/p1

DBの「トランザクション分離レベル」が必要な理由　（PostgreSQLで，ファントム・リードを防止すべきサンプル事例）
http://language-and-engineering.hatenablog.jp/entry/20110104/p1

NULL撲滅委員会
http://www.geocities.jp/mickindex/dat...

パフォーマンスについて

インデックスを作成して，SQLの速度をチューニングする手順　（PostgreSQLで，EXPLAIN文とCREATE INDEX文によるパフォーマンス改善）
http://language-and-engineering.hatenablog.jp/entry/20110121/p1

セキュリティについて

そろそろSQLエスケープに関して一言いっとくか
http://www.tokumaru.org/d/20080601.html

SQLインジェクション対策の方針としては、リテラルを勝手に終端させないようにすることが必要

mysqlでskip-character-set-client-handshakeはもう使わないほうがいいと思われ
http://blog.everqueue.com/chiba/2009/...

クライアント側のコンパイル時のcharset, 送信内容のcharset, DBサーバ側のcharset

文字コードの乖離が起こると，２バイト目の \x5c が「\」と解釈されて危険な場合が

PHP+PostgreSQLでのSQLインジェクション対策
http://firegoby.theta.ne.jp/archives/28

処理系の日本語対応が不十分な場合、シフトJISで2バイト目が「\」(バックスラッシュ)のアスキーコードである「0x5C」になっている文字が入力されると「’」（シングルクオート）が「\(0x5C)」にエスケープされます。これにより、SQLインジェクションを成立させることが可能となります

セキュリティ / Oracleでのエスケープ
http://d.hatena.ne.jp/teracc/20071230

$fooに「[0xA1]' OR 1=1--」のような、EUC-JPとして不正なバイトを含む文字列を与える

Oracleは「[0xA1]'」を1文字とみなし，エスケープが回避

ＳＱＬインジェクション対策をするから起こる、セカンドオーダーＳＱＬインジェクションとその対策
http://blog.goo.ne.jp/xmldtp/e/afe490...

admin'--に設定したパスワードがadminに設定されてしまい、他人のパスワードを変えられる

システムテーブル

PostgreSQLのシステムテーブル入門　（暗記用のSQL集）
http://language-and-engineering.hatenablog.jp/entry/20100220/p1

補助ツールやドキュメントについて

テーブル定義書から，Javaのエンティティクラスを自動生成する VBA マクロ
http://language-and-engineering.hatenablog.jp/entry/20081229/1230563126

CSEのダウンロード
http://www.hi-ho.ne.jp/tsumiki/

システムの寿命はコードで決まる！
http://www.atmarkit.co.jp/fdb/rensai/...

市場シェアについて

MySQL/世界でもっとも普及している、オープンソースデータベース
http://www-jp.mysql.com/why-mysql/mar...

ガートナー調査の2008年利用率シェア分布のグラフ。

Oracle, SQL Server, MySQL, DB2 が圧倒

資格について

資格「オラクルマスター・ブロンズ」の学習用リンク集（DBA，SQL基礎I）
http://language-and-engineering.hatenablog.jp/entry/20110214/p1

（３）中級者（開発プロジェクトで１人月としてカウントできる水準）

知識の網羅的な学習：

SQLアタマアカデミー
http://gihyo.jp/dev/serial/01/sql_aca...

達人に学ぶSQL
http://codezine.jp/article/corner/51

リレーショナル・データベースの世界
http://www.geocities.jp/mickindex/dat...

バッチ処理について

Oracle技術者のためのバッチアプリケーション開発講座（1）バッチアプリケーション設計のポイント
http://www.atmarkit.co.jp/fdb/rensai/...

【バッチFW】マルチスレッドのトランザクション処理
http://es.sourceforge.jp/forum/forum....

分散処理について

クラウド上のリレーショナルデータベースはなぜ難しいのか？ BASEとCAP定理について
http://www.publickey1.jp/blog/09/_bas...

スターバックスは2フェーズコミットを使わない
http://code.google.com/p/gregors-ramb...

徹底比較!! PostgreSQL vs MySQL　第４回：レプリケーションの比較
http://thinkit.co.jp/free/article/060...

アルゴリズムについて

自己結合の使い方
http://codezine.jp/article/detail/460...

自己結合の使いどころ：ランキング生成（自テーブルの１レコードを自テーブルの全他コードと比較するという操作だから）。ポイントはデカルト積により，自テーブルであっても別ものの比較対照としてduplidateされること

基礎から理解するデータベースのしくみ（4）
http://itpro.nikkeibp.co.jp/article/C...

JOINの３方式。（１）ネステドループ法，親基準に子を２重ループ，遅い。（２）マージソート法，親子共ソートして両者を１スキャン。（３）ハッシュ法，最速

SQLで集合演算
http://codezine.jp/article/detail/130...

UNIONと書いた場合はUNION DISTINCTみたいな意味になり,２テーブルの結合結果から重複行を排除する。UNION ALLなら排除しないしパフォーマンスよい。主キーある重複なしテーブルであれば　S UNION S = S　のようにべき等性が成り立つ

ロックについて

PostgreSQLと他商用DBの比較、機能の違い　〜MVCC、VACUUM〜
http://www.hde.co.jp/press/column/det...

シーケンスまたは連番付与機構について

シーケンスが時々、勝手にとび番となってしまい困っています
http://okwave.jp/qa/q27807.html

SEQUENCEは一意性を保証するものであり、連番を保証するものではありません。

トランザクションを使用可能なデータベースサーバは通常この現象が発生します。

データベースのテーブルに一意の連続した数値型のキーを設ける場合に、どんな手法を取っていますか？
http://q.hatena.ne.jp/1189402025?mode...

OracleでもSQL Serverでも無理

シーケンスでは，一意性と連続性の両方を担保することはできない。そういう処理を自前で実装するのも，コスト的に無理。同時実行性が失われるから。

資格について