さまざまな組織(現在約20のクライアント)の情報を保存するこのWebアプリ(phpとmysql)を作成しました。
現在のシナリオでは、クライアント関連の情報を個々のデータベースに保存するため、20個のクライアントデータベースと1個のマスターデータベースがあります。
ここでの主な利点の1つは、各クライアントデータベースが分離されると、クライアントアーティファクト(レポート、監査)などの番号付けが順序付けられることです。クライアントに安心感を与えます。
各DBには約15のテーブルがあり、テーブル内のほとんどの行は約2000です。これは最大で5000レコードまでバンプされると予想されます。
単一のdbレベルの変更を管理するということは、20個のデータベースを変更することを意味しますが、まれにそのような変更を行う必要がある場合、単一の関数呼び出しでこれを行うスクリプトを使用します。
私たちは共有ホスティング契約を結んでおり、私たちのISPは制限されたno。データベースの;そして、それがデータベースの集中化という観点から私を考えるきっかけになりました。すべてのクライアントデータをmasterデータベースに保存できるようにします。
もちろん、発生する重要な問題は次のとおりです。
a。アーティファクトシーケンスの維持(追加の参照キーを作成することで対処できます)b。速度とパフォーマンス(この場合、インデックスを作成して速度を上げることができます)c。セキュリティ:これは、クライアント情報を取得する各クエリとして管理されます。 client_idも追跡します
将来的には、ある組織のデータセットを別の組織と比較することを検討する必要があるかもしれませんが、それは集中データベースでも達成できると考えています。 (パフォーマンスと保守性の理由で)集中型データベースに移行する傾向があります。
一元化されたデータベースへの移行は、(個々のデータベース上で)そのままでいるよりも理にかなっていると思いますか?
アドバイスありがとうございます。
両方のシステムには継承のリスクと報酬があります。私は1つのデータベースで約40のクライアント(国立銀行)をサポートする金融会社で働いていました。次に、同様のソフトウェアを販売し、クライアントごとに1つのデータベースを使用していた別の会社を購入しました。最後に、会社は倒産し、すべてのユーザーデータをエクスポートする必要がありました。私が一緒に働いて、見つけた人々は次のとおりです。
シングルDBの長所:
シングルDBの欠点:
複数のDBの長所:
コンの複数のDB:
最後に、両方を見て、行った私の推奨事項は、「規律」を持つことです! multi-dbの選択はあなたを保護するので少し良いと思いますが、クライアントだけに機能を追加させる選択をクライアントに任せることはできません。そうしないと、失敗への道を歩むことになります。
クライアントごとに個別のデータベースが必要です。クライアントはセキュリティ上の理由でこれを要求する場合があります。つまり、自分のサイトのみがデータにアクセスできます。また、クライアントがデータを移動したい場合、much管理が容易になることも意味します。
また、あるクライアントのデータベースに問題がある場合、他のすべてのデータベースに影響を与えないことも意味します。
クライアント間でデータを比較する場合は、個別に比較する必要があります。
使用できるデータベースが不足している場合は、おそらくホストプロバイダーの変更を検討する必要があります。
これまでにリストされたプロ/コンに追加するには:
Proの複数のデータベース:
ロックの問題は回避されます。クライアントがいくつかのテーブルでDDL変更をトリガーできるデータベースがあります。大きなテーブル(> 2mレコード)の場合、これはかなりの時間テーブルをロックします。不利な立場にいるのは自分のユーザーだけなので、これは許容範囲内です。
柔軟性-一部のクライアントは、保存したいデータに関して特定の要望があります。マルチデータベースにより、他のクライアントのデータモデルを乱雑にすることなく、データベースを明確に変更できる柔軟性が得られました。
短所:
選んで頑張ってください!
既に回答を選択していることは知っていますが、提案されていない別の解決策があるようです。
すべてを1つのデータベースに移動しますが、次のようにプレフィックスを使用して顧客ごとにテーブルを作成します。
initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl
それは両方の長所の一種です。
私が各クライアントに個別のデータベースを持っていない唯一の理由は、あなたが100または1000のクライアント/データベースを持つことになっている場合です。これは、データベースの変更やすべてのデータベースでの操作など、管理が非常に困難になる可能性があります。多数の複数のデータベースで発生するアクションも、非常に多くのテーブルを開く(したがって閉じる)必要があるため、遅くなる可能性があります。
しかし、この場合は別として、複数のデータベースの方が良いと思います。
重要ではないかもしれないが便利な利点の1つは、各クライアントが独自のシーケンシャルIDを取得することです(別のクライアントがレコードを追加したために束をスキップするのではなく)。
また、複数のデータベースにより、サブテーブル(電話タイプなど)をクライアントごとに簡単にカスタマイズでき、これらのテーブルに親レコードIDも必要ありません。
まず、アーチファクトシーケンス。これを提供するために整数の主キーを使用していると思います。本当に別の「アーティファクト番号」列があるはずです。 PKはPKである必要があります。人々は「自然の鍵」などについて話します。識別子以上のものであるとPKに頼るときはいつでも、それはあなたに噛みつきます。何かのシーケンスを知りたい場合は、日付またはシーケンス番号を保存します。
あなたの場合、構成管理はあなたを単一のデータベースに導くと思います。データベースの保守とアップグレードに要する時間を検討してください。ソフトウェアの各リリースにはどのような費用がかかりますか?また、新しい顧客を獲得し、DBを作成してアプリを構成する必要がある場合のコストについても考えてください。自動化できるものは何でもあります。質問は、100個のデータベースがある場合に価値があるかどうかです。
将来的には、100個のデータベースに対して同じことを行うよりも、単一のデータベースをスケーリング(パーティション分割、ハードウェア、シャーディングなど)する方が簡単です。
私は他のポスターがいくつかの優れた点を指摘していると思うので、それらについては触れません。