単一V / s複数データベース

さまざまな組織（現在約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の長所：

1. ソフトウェアの更新とバグ修正が簡単になりました。
2. すべてのクライアントデータの管理とレポートが簡単です。
3. データの更新が簡単になります。
4. 1つのクライアントが必要とするモジュール機能を簡単に作成し、他のクライアントの場合はオフにし、将来必要に応じて1つをオフにします。

シングルDBの欠点：

1. データの整合性-1つの銀行のユーザーが別の銀行のデータを見た場合、2つまたは3つのケースがありました。これは悪夢でした。特に、サイトのユーザーは銀行の従業員だけでなく、銀行の顧客を保持している実際の口座だからです！これは、1つのデータベースの最大の問題です。
2. クライアントデータのエクスポート-これが必要になったとき、通常は大したことではありませんでした。最終的に、すべてのクライアントを含む1つのテーブルになり、そのテーブルからキーオフして、クライアント固有のデータを取得します。

複数のDBの長所：

1. クライアント間のデータ汚染や違反の心配はありません
2. クライアントデータのエクスポートは非​​常に簡単です。

コンの複数のDB：

1. アップデートとバグ修正-これは本当の悪夢でした。20の異なるデータベースに20のクライアントがある場合、1人のクライアントがバグの修正を望み、別のクライアントがバグが機能であるか更新の危険を冒したくないと考えるケースにすぐに出くわします。さらに、1人のクライアントがゲーム変更の強化を望んでいるが、他のクライアントはそれを望まない場合があります。これが発生すると、データベースが分岐し始めます。突然、クライアント1〜15を1つのスクリプトで更新し、16〜19を別のスクリプトで更新し、20を3つ目のスクリプトで更新する必要があります。これは、すべてのクライアントですべてのテストを実行し、各クライアントの特別なコードを処理する必要があるため、購入した会社のバグ修正にかかる時間が私たちよりも15から20倍かかるような問題になることがわかりました。事実上、新しいクライアントごとに新しいサポート担当者が必要でしたが、
2. DB管理-多数のクライアントがすべてのデータベースを管理するようになると、本当に面倒になります。あなたは間違いなくそれらを管理するためにより多くのDBA時間を必要とするでしょう。

最後に、両方を見て、行った私の推奨事項は、「規律」を持つことです！multi-dbの選択はあなたを保護するので少し良いと思いますが、クライアントだけに機能を追加させる選択をクライアントに任せることはできません。

クライアントごとに個別のデータベースが必要です。クライアントはセキュリティ上の理由でこれを要求する場合があります。つまり、サイトのみがデータにアクセスできます。また、クライアントがデータを移動したい場合、管理がはるかに簡単になることも意味します。

また、あるクライアントのデータベースに問題がある場合、他のすべてのデータベースに影響を与えないことも意味します。

クライアント間でデータを比較する場合は、個別に比較する必要があります。

所有できるデータベースが不足している場合は、おそらくホストプロバイダーの変更を検討する必要があります。

私が各クライアントに個別のデータベースを持っていない唯一の理由は、あなたが100台または1000台のクライアント/データベースを持っている場合です。これは、データベースの変更やすべてのデータベースでの操作など、管理が非常に困難になる可能性があります。多数の複数のデータベースで発生するアクションも、非常に多くのテーブルを開く（したがって閉じる）必要があるため、遅くなる可能性があります。

しかし、この場合は別として、複数のデータベースの方が良いと思います。

重要ではないかもしれないが有用な利点の1つは、各クライアントが独自のシーケンシャルIDを取得することです（別のクライアントがレコードを追加したために束をスキップするのではなく）。

また、複数のデータベースを使用すると、サブテーブル（電話タイプなど）をクライアントごとに簡単にカスタマイズでき、これらのテーブルに親レコードIDも必要ありません。

まず、アーチファクトシーケンス。これを提供するために整数の主キーを使用していると思います。本当に別の「アーティファクト番号」列があるはずです。PKはPKである必要があります。人々は「自然の鍵」などについて話します。識別子以上のものであるとPKに頼るときはいつでも、それはあなたに噛みつきます。何かのシーケンスを知りたい場合は、日付またはシーケンス番号を保存します。

あなたの場合、構成管理はあなたを単一のデータベースに導くと思います。データベースの保守とアップグレードに要する時間を検討してください。ソフトウェアの各リリースにはどのような費用がかかりますか？また、新しい顧客を獲得し、DBを作成してそのアプリケーションを構成する必要がある場合のコストについても考えてください。自動化できるものは何でもあります。質問は、100個のデータベースがある場合に価値があるかどうかです。

将来的には、100個のデータベースに対して同じことを行うよりも、単一のデータベースをスケーリング（パーティション分割、ハードウェア、シャーディングなど）する方が簡単です。

私は他のポスターがいくつかの優れた点を指摘していると思うので、それらについては触れません。

これまでにリストされたプロ/コンに追加するには：

Proの複数のデータベース：

1. ロックの問題は回避されます。クライアントがいくつかのテーブルでDDL変更をトリガーできるデータベースがあります。大きなテーブル（> 2mレコード）の場合、これはかなりの時間テーブルをロックします。不利な立場にいるのは自分のユーザーだけなので、これは許容範囲内です。

2. 柔軟性-一部のクライアントは、保存したいデータに関して特定の要望があります。マルチデータベースにより、他のクライアントのデータモデルを乱雑にすることなく、データベースを具体的に変更する柔軟性が得られました。

短所：

1. 主要な短所：他のテーブルに参加するのはずっと面倒です。ほとんどのメタデータを含むメインデータベースがあります。クライアント固有のデータベースユーザーはこのデータベースにアクセスできないため、そのデータベース内のテーブルとクライアント固有のテーブル間のすべての結合は、データベースではなくアプリケーションで処理されます。これを解決するには、クライアント固有のユーザーにメインデータベースへのアクセス権を付与しますが、アプリは再び情報をリークする可能性があります。

選んで頑張ってください！

既に回答を選択していることは知っていますが、提案されていない別の解決策があるようです。

すべてを1つのデータベースに移動しますが、次のようにプレフィックスを使用して顧客ごとにテーブルを作成します。

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

それは両方の世界の最高の一種です。

• 現在のセットアップから新しいセットアップへの移行は非常に簡単です。
• クライアントごとに1人のユーザーを作成し、その権限を彼の会社のテーブルのみに制限できます。
• スーパーユーザーを作成し、必要に応じて簡単にデータを集約できます。
• 1つのデータベースのみを使用する