これだけは覚えておきたい!!MySQL の６つの自動変換 - sakaikの日々雑感～(T)編
MySQLはとても気ぃつかい屋さんである。我々が投げる多少あいまいな指示も頑張って解釈し、なんとか文句を言わずに実行してみようと挑戦してみてくれる。 今日はそんなMySQLがケナゲに解釈してくれる自動変換について紹介しようと思う。この自動変換、ケナゲなMySQLの奥ゆかしさ故、出した指示と異なる動作をされたことに気がつかないことがある。ここで紹介する６つの自動変換をしっかり脳ミソにたたき込んでおけば、無用なトラブルにハマる時間も減るかもしれない。 １．[数値] 範囲外の数値は頭を押さえつけられる intやsmallint、bigintなどの数値型には、扱える範囲が決まっている。例えばint型なら最大21億ちょっとだ（unsignedの場合は43億弱）。これより大きい数字を登録するよう指示を出すとMySQLはどうするか。そう、頑張って入れられるところまで入れてくれるのである。「入れられるとこ
第7回 性能改善の鍵、インデックスの特性を知る～B-treeとハッシュ （3）結論 | gihyo.jp
総評 以上、B-treeとハッシュという代表的なパフォーマンスチューニングのアルゴリズムについて見てきました。どちらの技術を採用するかは、業務要件に依存するところが大きいのですが、ここで目安として一般的な結論も述べておきましょう。 結論1：とりあえずB-treeインデックスを使って大敗することはない。 B-treeはバランスのとれたオールラウンダーですので、だいたいどんな要件にもそこそこ対応します。安心して使ってください。 一方、ハッシュについての結論は、こうです。 結論2：等値条件で性能を追求したいならハッシュを使いなさい。ただし大敗も覚悟しなさい。 ハッシュが効果を発揮するのは、等値条件（=）のときだけです。また、ソート処理の助けにもなりません。したがって、使う局面は非常に限られてきます。PostgreSQLのように、マニュアルに「ハッシュインデックスの使用は推奨しない」とはっきり書い
第6回 SQLで木構造を扱う～入れ子区間モデル （1）もしも無限の資源があったなら | gihyo.jp
はじめに 前回では、入れ子集合モデルという、リレーショナルデータベースで木構造を扱うための新しい方法論を紹介しました。このモデルは、RDB、SQLと親和性の高い優れたものではあるのですが、挿入など更新時に、無関係のノードまで変更対象としなければならないのが大きな難点でした。 そこで今回は、上記の欠点を解消する進化版のモデルを紹介します。この方法を理解していく過程で、私たちはRDBと集合論の結び付きの深さを再確認することになります。 ふだんこの連載は、1回完結の読み切り形式なのですが、今回に限り、前号の内容を前提としています。未読の方は、前号を先に読むと理解が増すでしょう。 稼働環境 すべてのリレーショナルデータベース もしも無限の資源があったなら 座標に整数のみを使う場合の限界 入れ子集合モデルの大きな欠点は、ノードを挿入（追加）するときに、自分より「右側」にある無関係なノードをもっと右へ
SQL Azureの概要とSQL Azure Databaseを使ったアプリケーション開発
はじめに 今回は、Windows Azure Platformにおいて、クラウド上のデータベース機能を提供する「SQL Azure」について扱います。そして、SQL Azureの中核となるSQL Azure Databaseを使ってサンプルアプリケーションを作成してみます。 対象読者 Windows Azureに興味がある方 SQL Azureに興味がある方 SQL Azure Databaseを使用してアプリケーションを開発したい方 必要な環境 シリーズ第1回、第2回を参考にして、Windows Azureの開発環境のインストール、そしてクラウド環境に配置するために必要なAzure Services Developer Portalのアカウント作成とトークン取得を行ってください。 さらに、サンプルでは最初にSQL Serverにアクセスするアプリケーションを作成しますので、SQL Ser
第5回 SQLで木構造を扱う～入れ子集合モデル （2）入れ子集合モデルにおける検索 | gihyo.jp
入れ子集合モデルにおける検索 ルートとリーフを求める まず入れ子集合の検索で基本となる考え方を理解しましょう。それは「包含関係を調べる」ことです。 たとえば、ルート（ここで言う足立社長）とリーフ（猪狩、木島氏ら）を求めることを考えます。リーフの円は、自分の中に下位の円を一つも含まないという特性を持ちます。したがって、NOT EXISTSによって表現できます（リスト1、図5）。 リスト1 リーフの円を求める SELECT * FROM OrgChart Boss WHERE NOT EXISTS (SELECT * FROM OrgChart Workers WHERE Workers.lft > Boss.lft AND Workers.lft < Boss.rgt); 図5 リスト1の実行結果
H2k6 [旧Hogehoge2006(仮)]
データベース型の音楽プレイヤーです。(フリーソフト) 手持ちの曲が数千～数万のオーダーでも快適に曲を探せるようなコンセプトで作られようとしています。 名前はH2k6にしました。アイコン＆デフォルトジャケット画像募集 ■特徴 データベース(SQLite)で曲を管理 ファイル名やタグ・評価から曲をリンク・検索できます。 また、クエリーの作成によってiTunesのスマートプレーリストの様なモノを実現します。 元のファイルは一切変更しない。 評価などの独自項目はすべてデータベースに保存され、元のファイルには一切変更を加えません。 ジャケット表示 曲の再生と同期してジャケット画像の表示を行います。 ※MP3/MP4/WMAのAPIC又は設定したパターンの画像ファイルに対応 歌詞表示 タイムタグがある場合、曲の再生と同期して歌詞の表示を行います。 関連アルバムの表示 再生中のアーティストが含まれる他の
SQL Serverのインデックス構造（前編）
SQL Serverのインデックス構造（前編）：SQL Server 2000 チューニング全工程（4）（1/2 ページ） 本連載ではSQL Server 2000のチューニングに関するノウハウを解説する。SQL Server 2000は自動チューニング機能を持つために、チューニングはあまり必要ないと思われがちだが、そのアーキテクチャを理解し適切にツール類を使用しなければ、本来のパフォーマンスを得られない。（編集局） インデックスはなぜ必要か インデックスはデータベースの索引というべきものです。書籍の中からある項目について調べたい場合、書籍の内容をすべて読むのではなく、索引を有効に活用して必要な情報を取り出します。データベースにおいてもデータベースに含まれるデータの場所を索引としてあらかじめ生成しておけば、データの検索が効率的に行えると期待できます。検索処理は、SELECT文によるデータの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
