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