なんでもいいや、ぐらいに思ってました)。パフォーマンス比較をしたことがありました。して使える機能は一通り揃っているな~。チャンスがあったらいつか使ってみたいな。」と感想をもったことを思い出しました。コーディングしました。対してなにも不満がなかった、というか開発を通して素晴らしいデータベースであると強く思うようになり、浮気せず使い続けることとなったのでした。よる内部取得」を採用しました。それによりコーディング量がぐっと減り、ラクさせてもらいました。導入することにしました。2台の間で不整合がでることが判明。サーバーがそれぞれ別のシリアル番号、微妙にずれた(ミリsecレベルのずれ)タイムスタンプを取るようになったためでした。出すようになったのです。文構築してから使う旨の記述を発見......。導入を断念するはめになってしまいました。側に登録する形で落ち着きました。この程度の緩い同期で実質問題は発生しませんでした。文の組み合わせでトランザクションを構成したので、分かりやすいソースにはなりました。あとで他のメンバーたちが開発に参加してきた際も、その点はいい方に働きました。実運用に入り、アクセス数が伸びてくるに従い、システムのレスポンスの遅さが大きな問題になってきました。部分がボトルネックになっていることが判明したため、下記のような改造をすることにしました。活用し、ソースを全面見直ししました。力をなるべく引き出すソースに改造しました。つかって、コストをかならず把握してからコーディングするようにしました。カーソル関数はデータ件数が多い時オーバーヘッドが大きかったので、カーソル関数を避けるようにしました。いった改造によりレスポンスが劇的に向上し、その後、伸び続けるアクセスにも対応できるようになりました。倍かそれ以上のレスポンス向上があったと記憶しています。運用時のエピソードエピソードその1運用に入ってから、オープンソースの決済系システムを導入して、連携させることにしました。いうもので、簡単に移植できませんでた。まま使えるようにする。