Effective SQL | 翔泳社
どれだけクライアント側のUXが変わっても、アルゴリズムが変更されても、変わらないのがリレーショナルデータベースの世界。それだけに経験値とベンダーごとに微妙に異なる方言を操るための“鍛錬”は必須の世界といえます。 しかし“鍛錬”は、それこそ思考し手を動かさなければ鍛錬とは言えません。 そこで本書では、単なる教科書的なSQL文の組み立て（鍛錬の方法）を超えて、さまざまなケースにマッチした最適なSQLを自然に記述できるようになるための知見と勘所を、具体的なテーブルやDB構成とともに解説します。 そのためSQL方言は極力排し、標準SQLで解説を行い、各サンプルの方言版はGitHubで公開するという方法を取っています。 つまり、 ・解くべき問題を明確にし、 ・次にその解決方法を整理し、 ・考え方を標準的なやり方で提示し、 ・必要であれば方言でも参照できる、 というスタイルです。 SQLの現場ですぐに
RDBにおけるキャッシュという考え方
RDBの専門家として日々活動している中で気づいたことのひとつに、「RDBはデータへのアクセスの実装をインデックスに頼っているが、インデックスは全ての問題を解決できるほど万能ではない」ということがある。インデックスというのはとても強力な部品であり、その点には全く異論はない。だが、世の中の全ての問題（クエリ）を解決できるほど、柔軟性に富んだものではないということだ。RDBは、どのインデックスを使ってデータへアクセスするかということを、オプティマイザを用いて判断する。大抵のRDB製品では、オプティマイザはよい仕事をするので、インデックスとオプティマイザの組み合わせによって、ほとんどの問題に対応できる。だが、100%ではないのであり、そのようなケースがシステムの性能問題を引き起こしたり、プログラマ（アプリケーションの設計者）に、NoSQLへ完全に移行したり、クエリ高速化のために非正規化をすると言っ
論理削除が云々について - mike-neckのブログ
今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基本的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意
関数プログラミングのボトルネックとしてのRDBMS
プログラム開発は、多くの人々が目的達成のため、もがき苦闘するタールの沼である – Frederic P. Brroks, Jr., 人月の神話 モジュール性はプログラミング成功の鍵である – John Hughes, 関数プログラミングはなぜ重要か タールの沼の底から タールの沼と聞いて連想するのは大規模なSIである。業務アプリケーションやWebアプリケーションは規模が大きくなればなるほど、複雑さが増し収拾がつかなくっていく。そしてそのようなアプリケーションを大きな単位で上手くモジュール化し、さらには再利用することは不可能に近い。 その技術的な原因の一端、そして問題を解く鍵は、そのようなアプリケーションが常に携えているRDBMSの周辺にあり、さらに言えばおそらくRDBMSとアプリケーションロジックの組み合わせにあると考えている。 ここでは、アプリケーションロジックの実装に関数プログラミング
RDBMSで使われるB木を学ぼう （1/3）－ ＠IT
第5回 RDBMSで使われるB木を学ぼう はやしつとむ アナハイムテクノロジー株式会社 2009/6/22 オブジェクト指向によって、アルゴリズムは隠ぺいされていることが多くなった。しかし、「用意されていない処理」が求められたときに対応できるだろうか（編集部） 第3回「AVL木で木構造を学ぼう」、第4回「もっとAVL木で木構造を学ぼう」と2回連続でAVL木について解説しました。 今回はAの後だからBというわけではありませんが、B木（B-Tree）を取り上げます。 B木の変種であるB+木やB*木は、OracleやPostgreSQL、Firebirdなどのリレーショナルデータベースでインデックスとして利用されている、メジャーな木構造です。 筆者はDelphi 2009でサンプルプログラムを作成していますが、Delphiをお持ちでない方は下記のURLからTurboDelphiをダウンロードして
なぜBTreeがIndexに使われているのか - maru source
※この内容は個人的な考察なので、間違っている箇所もあると思います。そういう部分を見つけた際はぜひ教えて下さい。 RDBMSの検索を早くするためにIndexって使いますよね。例えばこんなテーブル CREATE TABLE user ( id INT UNSIGNED NOT NULL, name VARCHAR(255) NOT NULL, UNIQUE INDEX (id) ); idカラムにIndexを張っています。これはidでの検索を高速にするためです。ここでidカラムにIndexが貼っていない場合と比べると検索時間が大幅に変わってきてしまいます（特にレコードが多くなった時) ではなぜIndexを貼ると検索が早くなるんでしょう？？ Indexとはその名の通り索引を意味します。特定のカラムの索引を作成しておくことで検索を高速化します。 (本の最後によみがな順で単語が並べられたりしています
RDBMSでコネクションプールが必要な理由、わからない。
Takayuki Shimizukawa @shimizukawa @masa_edw コネクションプールが無い場合、使い終わったコネクションが即解放されない（解放まで多少遅延する）ので実際に使っているコネクションの数より多く存在する。その分メモリを圧迫して効率が悪い。っていう話は聞いたことがあるよ（要出典 2013-09-04 09:27:28 ハイパーむとう @masa_edw @voluntas 現状で必要な状況は理解していますが、なぜそうなるのか理解していないということです。他にもたとえば、bitlyの呼び出しはコネクションプールを使うべきか？なぜ(べき、べきでない)のか？どういう要請でそうなのか？と言う問いに僕は答えられません。 2013-09-04 09:31:22
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLテーブル設計入門