次のSQL標準は何が盛り込まれる？ －第2回DBオフライン
DBオンラインチーフキュレーター 谷川耕一さん 谷川：ここからはDBオフラインです。1回目に続き、SQLの話をしていきます。なぜ私が聞き役になれるかというと、DBオンラインのチーフキュレーターをしているのと、前職でオラクルでマーケティングをしていてSQLは書く程度なら経験があるからです。まずは土田さんから自己紹介をお願いします。 日本データベース学会 副会長 土田正士さん 土田：普段は日立製作所に勤めています。日本データベース学会の副会長もしています。ここ15年ばかりISOにてSQL標準に策定に携わり、規格を開発しています。標準の策定をしつつ、会社の製品に反映するということをしています。 谷川：日本データベース学会は今回のイベントの後援もしてくれています。日本データベース学会は来るもの拒まずらしいので、私も入会したところです。 土田：興味がありましたら「DBSJ」でググってみてください。私
新著が出ます：『SQL実践入門』 - ミックのブログ
4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にした本で、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、本当は実行計画などという手続レベルの世界をユーザが覗き見るのは、本末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体本当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。
開発者のためのSQLパフォーマンスの全て
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
Oracle 実用的で簡単なヒント句のつけかた
なんていう大それたタイトルをつけると 全然わかってねーだろ！と怒る人もいるかと思いますが… （私はOracle Masterも持っていない人ですし） なぜかSQLチューニングやらを仕事でやらされることが多く、 しかしチューニング関係の本やサイトは意味不明すぎて。 そんな中、実際にとんでもないＳＱＬとかをなんとか早くする為に 編み出したヒント句のつけかたを紹介します。 軽い気持ちで読んでください。 つけるべきヒント句は６種類だけ だいたいがOracleに任せておけばいいんです。 ヒント句をがっぷりつけたところで状況が変わったら対応できなくなりますので。 私が主につけるヒント句は以下だけです。 テーブル結合に係る部分だけですね。 ordered / leading inxex / full use_nl / use_hash 全部で６つです。これだけなら覚えられるでしょう。 他のは覚えきれない
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
