RDBの接続ばかりやってますが、基本的な設計の事も少し触れておきたいと思います。
RDBを利用するシステムを開発する上で、まずは考慮するポイントがいくつかあります。
その結果に応じて、どんなRDBを利用するかがほぼ決まります。
#——————————-
■ 1.規模はどれくらいか? ■
#——————————-
実際に投入されるデータは何件くらいでしょう?
実際に利用するユーザーは何名くらいでしょう?
それによって、検討するRDBの種類が決まってきます。
#——————————-
■ 2.データ更新の頻度と大きさは? ■
#——————————-
RDBは、日々内容が更新されていくのが前提です。
その場合に更新頻度は、日に何回くらいか?
ちょこちょこと、何十回も分けて更新されるのか?
一度に大きいデータをどかっと更新するのか?
#——————————-
■ 3.バックアッププラン ■
#——————————-
RDBは非常に信頼性の高いデータベースですが、万が一の時も考えなければなりません。
その為にデータベースに格納されているデータのバックアップを取ることが必要です。
どんな方法で取るのか?
どんなメディアに保存するのか?
#——————————-
■ 4.運用プラン ■
#——————————-
どのくらいの頻度で、いつ頃データベースを停止できるのか?
一日一回なのか?年に一回なのか?それとも停止できないのか?
それによって、バックアップ方法も変わります。
更新処理は日中だけならば、夜間に停止してコールドバックアップで良いですが、24時間稼動しているのならオンラインバックアップも検討しなければなりません。
#——————————-
■ NEXT ■
#——————————-
上記4ポイントを調査、検討すると次のステージです。
1の規模についてですが、数名程度でしたら「Access、sqlite」あたりが良いでしょう。
しかし、セキュリティを考慮する必要がある場合は直接コピーしてしまえるようなRDBでは少々都合が悪いのでもう少し上位のRDBを検討する事も必要でしょう。
2のデータの更新と頻度ですが、どかっとバッチ的に処理するのであればなんでも良いと思います。
そうでない場合は、データ更新時にきちんとログファイルを作成しているRDBが良いでしょう。
3のバックアップですが、一度に全てのデータを取りますか?それとも差分だけを取りますか?
これも対応できるRDBと出来ないRDBがあります。
4の運用プランですが、これは結構大事な項目です。
止める事の出来ないRDBだとオンラインバックアップ等も視野に入れなければなりません。
万が一の事を考えると、RDBのクラスタ化も検討が必要でしょう。
ここまで来ると、システムに採用するRDBはかなり絞られて来ると思います。
コメント(0)
コメントを受け付けておりません。