質問: 単一v / s複数データベース さまざまな組織(現在約20のクライアント)の情報を保存するこのwebアプリ(phpとmysql)を作成しました。現在のシナリオでは、クライアント関連の情報を個々のデータベースに保存するため、20個のクライアントデータベースと1個のマスターデータベースがあります。ここでの主な利点の1つは、各クライアントデータベースが分離されると、クライアントアーティファクト(レポート、監査)などの番号付けが順序付けられることです。クライアントに安心感を与えます。各dbには約15のテーブルがあり、テーブル内のほとんどの行は約2000です。これは最大で5000レコードまでバンプされると予想されます。単一のdbレベルの変更を管理するということは、20個のデータベースを変更することを意味しますが、まれにそのような変更を行う必要がある場合、単一の関数呼び出しでこれを行うスクリプトを使用します。私たちは共有ホスティング契約を結んでおり、私たちのispは制限されたno。データベースの;そして、それがデータベースの集中化という観点から私を考えるきっかけになりました。すべてのクライアントデータをmasterデータベースに保存できるようにします。もちろん、発生する重要な問題は次のとおりです。a。アーティファクトシーケンスの維持(追加の参照キーを作成することで対処できます)b。速度とパフォーマンス(この場合、インデックスを作成して速度を上げることができます)c。セキュリティ:これは、クライアント情報を取得する各クエリとして管理されます。 client_idも追跡します将来的には、ある組織のデータセットを別の組織と比較することを検討する必要があるかもしれませんが、それは集中データベースでも達成できると考えています。 (パフォーマンスと保守性の理由で)集中型データベースに移行する傾向があります。一元化されたデータベースへの移行は、(個々のデータベース上で)そのままでいるよりも理にかなっていると思いますか?アドバイスありがとうございます。
回答: まず、アーチファクトシーケンス。これを提供するために整数の主キーを使用していると思います。本当に別の「アーティファクト番号」列があるはずです。 pkはpkである必要があります。人々は「自然の鍵」などについて話します。識別子以上のものであるとpkに頼るときはいつでも、それはあなたに噛みつきます。何かのシーケンスを知りたい場合は、日付またはシーケンス番号を保存します。あなたの場合、構成管理はあなたを単一のデータベースに導くと思います。データベースの保守とアップグレードに要する時間を検討してください。ソフトウェアの各リリースにはどのような費用がかかりますか?また、新しい顧客を獲得し、dbを作成してアプリを構成する必要がある場合のコストについても考えてください。自動化できるものは何でもあります。質問は、100個のデータベースがある場合に価値があるかどうかです。将来的には、100個のデータベースに対して同じことを行うよりも、単一のデータベースをスケーリング(パーティション分割、ハードウェア、シャーディングなど)する方が簡単です。私は他のポスターがいくつかの優れた点を指摘していると思うので、それらについては触れません。