さまざまな組織(現在約20のクライアント)の情報を保存するこのWebアプリ(phpとmysql)を作成しました。
現在のシナリオでは、クライアント関連の情報を個々のデータベースに保存するため、20個のクライアントデータベースと1個のマスターデータベースがあります。
ここでの主な利点の1つは、各クライアントデータベースが分離されると、クライアントアーティファクト(レポート、監査)などの番号付けが順序付けられることです。クライアントに安心感を与えます。
各DBには約15のテーブルがあり、テーブル内のほとんどの行は約2000です。これは最大で5000レコードまでバンプされると予想されます。
単一のdbレベルの変更を管理することは、20個のデータベースを変更することを意味しますが、まれにそのような変更を行う必要がある場合は、単一の関数呼び出しでこれを行うスクリプトを使用します。
私たちは共有ホスティング契約を結んでおり、私たちのISPは制限されたno。データベースの; そして、それがデータベースの集中化という観点から私を考えるきっかけになりました。すべてのクライアントデータをmasterデータベースに保存できるようにします。
もちろん、発生するいくつかの重要な問題は次のとおりです。
a。アーティファクトシーケンスの維持(追加の参照キーを作成することで対処できます)b。速度とパフォーマンス(この場合、インデックスを作成して速度を上げることができます)c。セキュリティ:これは、クライアント情報を取得する各クエリとして管理されます。client_idも追跡します
将来、ある組織のデータセットと別の組織のデータセットを比較することを検討する必要があるかもしれませんが、それは集中データベースでも達成できると思います。(パフォーマンスと保守性の理由で)集中型データベースに移行する傾向があります。
一元化されたデータベースへの移行は、(個々のデータベース上で)そのままでいるよりも意味があると思いますか?
助言ありがとう。