栞/#db
key-valueストレージとRDBMSと。
「SSDを、メモリバッファの拡張としてとらえるか、HDDの拡張として使うかで、アプリケーションや、最適なアルゴリズムも変わることが示唆されており」
ER図が作成できるEclipseプラグイン。
CommonsのDbUtilsをより便利に拡張性をつける。
URLをDBにどう格納するか。URLの長さを考慮しつつ。
「正確さのために無駄なロックが発生したり、インデックスを肥大化させて、速度を犠牲にしてしまう。(よくあるパターンだと思う)」「細かいことを気にしなければコンピューターの性能はもっと引き出せるはず。」
FrinedFeedがMySQLを使ってデータを管理している方法。「実体の中身は Python のディクショナリを pickle し, zlib で圧縮したもの」、インデックスの役割をするテーブルを用意して非同期にデータ書き込み。joinもプログラムで。
サーバーサイドのプリペアードステートメントのメリットとは。「SQLの構文解析はプレースホルダのまま行われるので原理的にSQLインジェクションの可能性がない」「キャッシュされるのでSQLの実行効率が向上する」
メモリ上に保存するkey-value storage。ディスク書き出しにも対応、値としてリストやセットも設定可能。http://www.atmarkit.co.jp/news/200902/26/redis.html
Berkeley DB/H2/MySQLを単純なkey-value storeとして使った場合のパフォーマンス比較。「valueのサイズが増加したとき、H2とMySQLではある地点を境に急にパフォーマンスが劣化する」
PDOのプリペアドステートメントに関する実装。DB側に機構が用意されてない場合はPDOがエミュレートする、実際にはコンパイル時に対応DBのバージョンを考慮して動作が変わったりする。
SQLiteで空間座標（spatialなデータ）を扱えるようにする。
DBは人手をかけないと劣化するということが理解されてない、同意。
Tokyo Cabinetに実装されたテーブルデータベース。「SQLは喋らないけどうまい具合にテーブルが扱える小粋なツールです。」
テーブル名/フィールド名をクォートした場合の大文字小文字の区別の違い。
「RDBMSを利用したシステムのパフォーマンスは１０００倍どころでない差がつきます。」強く同意。
「RDBMSが唯一の永続化の実装ではなくて、他にも選択肢ができてきたよ（しかも理論的にはスケールするよ）ということ」
「RDBMSの終わりが見えてきたということではなく、個別のRDBMS依存の終わりが見えてきたということ」
「もしあなたが統合のプロトコルをSQLからHTTPに変えたら、それはあなたがデータベースを統合データベース(リンク)からアプリケーション・データベース(リンク)に変えられるということです。」
RDBMSからの脱却とか。流れとしては同意だけど。
特にDBをSSDに何とかして乗せる方向。耐久性とかどうなのかな。
Slim3のソースを元にJavaのコネクションプーリングの仕組みを解説。
「勿論開発者の技術の標準化という意味では、会社組織としてやる時にはSQLは便利なもので標準として使われるべきものではあるけど、極限のパフォーマンスを出すことと相容れるものではそもそもない。」
複数のDBに接続することを想定したプラグイン。レプリケーション対応。
「テーブル定義書エクスポーター(TDE)は既存のデータベースからテーブル定義書(Excelフォーマット)をエクスポートするツールです。」
軽量版のMySQLが作られるらしい。デフォルトはInnoDBになるとのこと。
SQLインジェクションに関する発表資料あり。
シンプルなO/Rマッパー。adodbのラッパー。
SQLのエスケープで「」のエスケープが必要な理由。
DBのバインド機構を使わないSQLのエスケープについて。