本書はDB設計やSQL記述の際に避けるべき事柄を1章で1つ、25個紹介する書籍です。リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗（アンチパターン）があります。本書はデータベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分け、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介します。複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅します。日本語版では、MySQLのエキスパートとして著名な奥野幹也氏によるアンチパターンを収録。データベースに関わるすべてのエンジニア必携の一冊です。 本書への称賛の声 監訳者まえがき はじめに I部 データベース論
生島さんが誰と闘っているのか知らないけど、ちょっと気になることをつらつらと。 SQLは最も高級言語 - SQLer 生島勘富 の日記 SQLは最も高級言語２ - SQLer 生島勘富 の日記 SQLとはなんぞや？ - SQLer 生島勘富 の日記 高級*言語* どうも生島さんは、「SQL は高級言語！」と言いつつ SQL の処理系 (RDBMS) のことを高級だと言っているようです。 言語が高級であることと、処理系の最適化が手厚いことをごちゃまぜにして、この言語高級！と言うのはまずいんじゃないでしょうか。別に、RDBMS を操作するための言語として SQL でなくたっていいのです。例えば Tutorial D/Industorial D もあるし、LINQ を SQL に変換せずに直接 DB の操作を行うような RDBMS/Linq to X と言うのも考えられます。 ここではとりあえず、
当日の中継も以下でご覧いただけます。 http://www.ustream.tv/recorded/8146586Read less
分かりにくいタイトルで手抜きですが。 漠然と書いている人が多いような気がして整理してみました。勝手に理解している人もいると思いますが、ものすごく重要なことですので完全に頭に入れてください。 皆さん、イメージあってますか？ 再利用する方もいるかも知れないのでエクセルも付けておきます。 句述語.xls
INとEXISTSは違います。 BETWEENと、不等号の組合わせなど、等価になる記述法はあるのですけれど、INとEXISTSは基本的に同じ結果を返すことが可能ですが、意味は違います。 この違いが分かるにはインデックスを理解する必要がありますので、まずは、インデックスのイメージをつけてください。 まずはイメージ ここでも、まずはイメージで考えましょうね。 あなたは先輩の結婚式の司会を頼まれましたとします。イロイロと準備がありますが、余興で歌を歌う人がいるとき、予めカラオケの番号を調べておくでしょう。 食事の間のBGMについては、ラブソングの入ったiPodをつないでランダムで流すことにしましょう。しかし、新郎新婦にとって（過去の恋愛経験上）都合の悪い曲があり、チェックしてはじいておくことにしました（なかなか、そつがない司会ですな）。 これらの処理をSQLにするならば……。 ■カラオケの番号を
SQLが分からないという人は、文法を理解しようとしてしまっていることが多い。ですが、私は文法解説は極力やりません。SQLは全体を把握してイメージでとらえないとまっとうに書けないからです。 SQLのSELECTは次の順で処理されます。 FROM・WHERE句の中のサブクエリ FROM・WHERE句（WHERE句の中の相関サブクエリ） GROUP BY句 HAVING句の中のサブクエリ HAVING句（HAVING句の中の相関サブクエリ） SELECT句 ORDER BY句 SQLが苦手だという人のほとんどは、最初に処理されるFROM句・WHERE句が理解できていません。SQLの基礎はFROM句とWHERE句で、これが理解できるだけで7〜8割できたのも同じですので、しっかりと身につけてください。 まずはイメージから TABLE_A と TABLE_B をそれぞれ B_ID と ID で結合する
SQuirreL SQL is hosted at: and IDEs used by SQuirreL developers: SQuirreL's SQL editor is based on: RSyntaxTextArea Feature highlights of 4.8.0: Saved Session Groups: store and restore groups of Sessions Cell detail display at the right of SQL results Cell detail display and cell detail popup support image display Renaming additional SQL tabs Fixed dark theme Java 22 compatibility Many more featur
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
このセクションでは、MySQL が ORDER BY 句を満たすためにインデックスを使用できるタイミング、インデックスを使用できない場合に使用される filesort 操作、および ORDER BY に関するオプティマイザから使用可能な実行計画情報について説明します。 セクション8.2.1.19「LIMIT クエリーの最適化」 で説明されているように、LIMIT を使用する場合と使用しない場合で ORDER BY が異なる順序で行を返すことがあります。 場合によっては、MySQL でインデックスを使用して ORDER BY 句を満たし、filesort 操作の実行に伴う余分なソートを回避できます。 インデックスのすべての未使用部分と追加の ORDER BY カラムが WHERE 句の定数であるかぎり、ORDER BY がインデックスと完全に一致しない場合でもインデックスを使用できます。 ク
MySQLのクエリキャッシュ機能ですが、SELECT文の内容によってはquery_cache_XXX変数の値に依らず無条件に結果がキャッシュされませんよね。 ではどんなキーワードを含んでいるとキャッシュされないのでしょうか。sql_yacc.yyとlex.hで確認してみました。 SQL_NO_CAHCE FOR UPDATE LOCK IN SHARE MODE CURRENT_DATE CURDATE CURRENT_TIME CURRENT_TIMESTAMP CURTIME CURRENT_USER DATABASE DATABASES LAST_INSERT_ID MASTER_POS_WAIT NOW ROW_COUNT SYSDATE UNIX_TIMESTAMP USER UTC_DATE UTC_TIME UTC_TIMESTAMP (ユーザ定義関数) (ストアドプロシージ
良し悪しはまた別に置いといて。 SQL::String - An object representation of a chunk of SQL - metacpan.org #!/usr/bin/perl use strict; use warnings; use Data::Dump qw(dump); use Perl6::Say; use SQL::String; sub ss { my ($sql, @params) = @_; SQL::String->new($sql, @params); } my ($country_min_population, $city_min_population) = (50000000, 1000000); my $sub_query = ss(q|SELECT Code FROM Country WHERE Population > ?|,
yukiです。ダイエットを始めて3kg減ったと思ったら、風邪を引いて見事に1kg増量。 運動しないと駄目ですね。あと残り20kg、道のりは遠いです。 さて今回は、「RDBで階層構造を扱うには？」です。 あるサイトを構築中に階層構造をもったカテゴリ構造にすることになり、どのようにDBで扱うか悩みました。 DBはMySQLを採用していたので、この時点でぱっと頭に浮かんだ選択肢は以下のようなものでした。 XML-DBを利用する 親カテゴリレコードのプライマリIDを子カテゴリレコードに持たせる 親を含めた『絶対パス』を名称として扱い、取り出した後にパース ファイルシステムに同様のディレクトリ構造を作り、毎回パースする (1)のXMLDBはオープンソースのeXistやXindice、Yggdrasillなど様々な選択肢がありましたが、カテゴリのみの利用な割にメンテナンスコストが高すぎるので見送りま
Leo's Chronicle: XML時代の終焉 ~ XMLから再びCoddへ
先日、ACM SIGMODの日本支部大会に招いていただいて、「Relational-Style XML Query (ACM Portal http://doi.acm.org/10.1145/1376616.1376650)」について講演をしてきました。Relational-Style XML Queryは、XMLという複雑な構造をもったデータに対して、SQLのようなテーブルデータへの検索に使われる言語で問い合わせする手法です。 この研究の肝は、木構造データといわれるXMLでも、実はそのほとんどがリレーション(Microsoft Excelのようなテーブル形式のデータ）の組み合わせと考えることができ、そのテーブル構造の情報（スキーマ）を使うと、検索が非常に簡単に書けるという点です。
集約演算を行うケースでは、行のサイズを小さく保つことはとても重要。アクセス頻度が低いコラムは別テーブルに追い出すとかしたほうがいいくらい。 一方、集約演算を行わないケース (単一行の insert, update 等を含む) の場合は、(クライアントとの通信のための) システムコールがオーバーヘッドになるので、小さなテーブルにたくさんアクセスをするよりも、長い行を持つテーブルに１回アクセスするほうが良い。 たとえば手元の環境での insert on duplicate key update の速度は、 行のサイズ 必要時間 0KB 1 3KB 4 6KB 7 9KB 13 12KB 13 とかそんな感じ (環境やクエリによる変わるので自分で測定してね。9KB の速度低下はページサイズの1/2を超えたからかな)。つまり、行のサイズが1KB程度だと、通信のオーバーヘッドが大きいからあまり問題に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 達人に学ぶSQL徹底指南書: 初級者で終わりたくないあなたへ: ミック: 本
Amazon.co.jp: Head First SQL ―頭とからだで覚えるSQLの基本: Lynn Beighley (著), 佐藤直生 (監訳), 松永多苗子 (翻訳): 本
