リレーショナル・データベースの世界サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは本日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。
MySQLノウハウ
いろいろな本からメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),
MySQL負荷分散のまとめ - Life on the net
はてぶで人気エントリーになっていた、 http://kokoromo.jugem.cc/?eid=195 [MySQL：１台しかない環境で負荷分散] これは負荷分散＝スケールアウトというよりは一台でスケールアップしてしのぐ手段を書いてい。 だから負荷分散という言葉は必ずしも正しくないのだが、一つのテーブルへの付加集中を分散させるという事なのだろう。 そこで何パターンかあるMySQLの負荷分散を簡単にまとめてみる。 1. 富豪的分散 商用のクラスター製品を使う。 最近はMySQL専門のクラスター製品が出てきている。 http://www.continuent.jp/pro.html なんかは良いかなと思う。 長所： プログラム側ではクラスタ状態を何の意識もせず、一つのターゲットに対してクエリーを発行すれば良い。 ターゲットが複数台ある事は意識する事は無い。 不具合があるノードに生じた場合、他
MOONGIFT: » 凄いテキストデータベース「txtSQL」:オープンソースを毎日紹介
はてなブックマークのコメントより。 昨日お伝えしたGladius DBの対抗馬として紹介したい。こちらもまた、テキストファイルをDBとして扱うことができる。さらにGladius DBへの挑戦なのか、ベンチマークを公開している。 今回紹介するオープンソース・ソフトウェアはtxtSQL、テキストベースのデータベースソフトウェアだ。 txtSQLはGladius DBとは異なり、SQL文を解釈しない。独自の関数にアクション（SELECT/INSERT/UPDATE/DELETE等）、テーブル名、データ、WHERE句などを指定して渡す必要がある。 そのため、既存のアプリケーションを乗り換えるには修正が必要になってしまうのが難点だ。だが、新規開発であれば関係ないだろう。また、その結果として高速性が売りだ。Gladius DBの10倍近いパフォーマンスが出ている。 面白いのは、サンプルアプリケーション
PASSJ - SQL Server ユーザーグループ
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネット(株) が運営する国内シェアNo.1のドメイン登録サービスです。
【ハウツー】使ってみようH2 Database Engine - 最強の呼び声もあるすごいヤツ (1) 最強? H2 | エンタープライズ | マイコミジャーナル
組み込みデータベースといえばApache Derby、H2 Database Engine、HSQLDB、Berkeley DBなどが有名だが、このなかでも高いパフォーマンスで注目を集めているデータベースがH2 Database Engine(以降、H2)だ。先日Apache Derbyの最新版がリリースされたが、H2も最新版が公開された。 図.1 H2のサイト – トップページに掲載されているパフォーマンスグラフに自信がかいまみれる H2の組み込みデータベース最強という呼び声は、H2のサイトに公開されているパフォーマンスグラフの結果によるものだ。真偽のほどは各個評価して欲しいが、組み込みにおける実行性能に自信があるようすは伺える。
suVeneのあれ: 俺的コーディングルール SQL編
2007年01月19日 俺的コーディングルール SQL編 プロジェクトのコーディングルールがこうでなければいけないとか、他人に強制するわけではないが、自分自身で一貫性の無いコードを書くのは気持ち悪いので、オレオレルールを決めてたりする。大抵は デ・ファクト的なルールに沿う形で書くことが多いのだが、SQL や PL/SQL に関してはなかなかデファクトと呼べるものがないので(あるのか?)、メモ的に書きとめておく。 原則キーワード小文字オブジェクト名大文字カンマは後ろインデントは半角スペースで 2一つの SQL 文でキーワード毎にインデントしない(副問合せ除く) まず、1.2. に付いてなのだが、昔は「キーワード＝大文字」という意味不明な先入観で大文字で書いていた。ただ、それだと PL/SQL のキーワードも大文字、オブジェクト名も大文字で結局ほとんど大文字になってしまうのと、Shift 押す
CodeZine：楽々ERDレッスン 第2回：「図書館の予約申込書」編
はじめに おかげさまで、前回の記事は多くの方々からご好評をいただけたようでほっとしております。あちこちのブログなどを拝見していますと、記事をきっかけにして身近な例でERDを書いてみた方も見受けられます。今回も身近な題材でデータベース設計というものを考えていきたいと思います。 合言葉は、「量は質に転化する」。では、今回も張り切って行きましょう。 対象読者 データベース設計の初心者～中級者。 必要な環境 以下のいずれかのRDBMS。 PostgreSQL 8.0以上 MySQL 4.0以上 HSQLDB 1.7.2以上 MaxDB 7.5以上 Oracle 10g以上 SQL Server 2000以上 題材 今回の題材は、近所の図書館にあった書籍の予約用紙（図1）です。子供たちと本を借りに行った際にカウンターに置いてあったので早速利用することにしました。では、デー
DBという中間搾取 : 404 Blog Not Found
2007年05月22日16:15 カテゴリiTech DBという中間搾取 これは事実の半分に過ぎない。 naoyaのはてなダイアリー - Linux のページキャッシュ ということでデータサイズを見てページキャッシュに任せられそうなサイズなら OS に任せておくのが良いんじゃないかなと思います。まず、Disk Cacheはreadには強くても、writeにはそれほど強くないということ。以下をご覧いただきたい。これは、/usr/shre/dict/wordsをBerkeley DBに変換するというトリビアルな例で(ソースは後ろ)、./が普通のdisk,/mdがmemory disk(md)。読み込みに関しては差が全く出ていないのに、書き込みに関しては有意に遅い。 # write /usr/share/dict/words => ./words.db: 10.1032350063324 sec
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://labs.cybozu.co.jp/blog/kazuho/archives/2008/01/hdd_sync.php