サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは本日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。
かなりながーいエントリになる予定なので,結論だけ最初に書くとこんな感じ. この話題については自分も あとで書く と言って書いてなかったので書いてみますよ。2006年の下期にもなってコネクションプーリングかよというツッコミもありそうですが、あとで書くといったら書くの。あとで読むといったら読む。 普通「コネクションプーリング」と言ったら、主に二つの役割があると思います。話を簡単にするためにウェブアプリケーションに限定して言及します。 ウェブアプリケーションから DB への接続を開けっ放しにして、接続に必要とされるオーバーヘッドをカットして双方の負荷を下げる。 ウェブアプリケーションと DB への接続を「使いまわす」ことで、同時接続本数を節約する。 というもの。 mod_perl で DB と接続維持するとコネクション数増えて云々という話は主に前者のみについての話になります。Apache::DB
JDOInstrumentsプロジェクトは12日、Javaベースのオブジェクト指向データベースエンジンであるJDOInstrumentsのβバージョンを公開した。JDOInstrumentsの特徴はデータへのアクセス方法としてJDO(Java Data Object)の実装を組み込んでいる点にあり、このためJavaプログラムからデータベース内の情報に対して高速に、そしてシームレスにアクセスすることができる。 JDOはJSR 12として標準化されているJavaオブジェクトを永続化するためのAPIである。通常、Javaオブジェクトを永続的に保存しておくためには特定のデータストア(例えばファイルシステムやデータベース)に特化したプログラミングが必要になる。JDOではアプリケーションとデータストア間を透過的にアクセスできるようにすることで、特定の環境に依存しない実装を可能にする。 JDOInstr
オブジェクトデータベースは、オブジェクト指向プログラミングで使うオブジェクトの形式で表現されるデータを格納するデータベースである。オブジェクト指向データベースともいう。オブジェクト指向プログラミングにおいて、オブジェクトをその接続構造(オブジェクトグラフ)ごと永続化するといった用途に利用するのが容易であるなどといった、オブジェクト指向プログラミングや、オブジェクト指向プログラミング言語との関連がある。 オブジェクトデータベースのデータベース管理システム (DBMS) を、 オブジェクトデータベース管理システム (ODBMS; Object DBMS) 、あるいは オブジェクト指向データベース管理システム (OODBMS; Object Oriented DBMS) という。 この項目ではオブジェクトデータベースそのものについての他、オブジェクトデータベース管理システム (ODBMS) につ
[ETGW0005]リソース"Materials/D4.ppt"は既に存在しています。 Tuigwaa 上でユーザエラーが発生しました。 許可されないアクセスや、不正な操作を行った可能性があります。 サービスが継続されない場合にはお手数ですが、サーバ管理者までお問い合わせ下さい。 トップページに戻る
DELETEと参照 Houndを通じてかれこれ1年以上、RDB(PostgreSQL)とORM(Cayenne)につきあってきた。そろそろ、この世界の味がわかってきたので、書きとめておく。 結論:DELETEは深遠な哲学的問題だ。 本題に入る前に、RDBの濫用について片付けておこう。 RDBは、あらゆるコンピュータ技術のなかで、もっとも濫用されている。積もりに積もった装飾をはぎとってみれば、RDBというシロモノは、ある面で比類なく優れているかわりに、それ以外の面では恐ろしく融通がきかない。オブジェクト指向がミニバンだとしたら、RDBはF1マシンだ。装飾に隠されてはいるが、本質は変えられない。このことを忘れて設計した人々は、あとで莫大な額のツケを請求される(こうしてOracleが儲かるわけだ)。 手始めに、行ロックを退けよう。トランザクションを開始するときには、トランザクションを終了するまで
QuantumDB Eclipse Plugin QuantumDB is a simple but powerful database access plug-in for the Eclipse Development Platform. QuantumDB allows you to: connect to databases using standard JDBC drivers review schemas, tables, views and sequences look up column, index and foreign key information issue ad-hoc queries or other SQL statements against the database manage, edit, and work with SQL files (*.sql
情報元 順序値の生成 準備(DB作成〜ユーザ作成) その他 コメント 情報元 mysql http://www.mysql.gr.jp Oracle http://otn.oracle.co.jp http://otn.oracle.com SQLite http://www.sqlite.org PostgreSQL http://www.postgresql.jp DB2 (IBM) http://www-6.ibm.com/jp/software/data/db2/ http://www.db2.jp/ informix (IBM) http://www-6.ibm.com/jp/software/data/informix/ InterBase (Borland) http://www.borland.co.jp/interbase/ FireBird InterBa
MySQLのネタ。 1台しかない環境でエセ負荷分散を行う。 MySQLで負荷分散を考えたとき、 1台目にマスターのDBサーバー、 2台目以降をスレーブのDBサーバーとして用いる。 マスターは更新系のみのSQL文を、 スレーブは参照系のみのSQL文を投げる。 こんな負荷分散を1台のサーバーで行う必要が出てきた。 現在1台でやっていて、ディスクIOが追いつかずに捜し求めた結果、下の形で落ち着いた。 1つのテーブルでインデックスを含めたサイズが 30MB〜100MBほどで安定している、という条件があるのですが かなり負荷下がります。 ※上記サイズは搭載メモリサイズによって変わります -------------------------- ■やりかた 負荷が高いテーブルをAとする 1:Aと同じテーブル構成で、エンジンをMEMORY(he
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く