私は何年もの間sql（主にmysql）を使用してきましたが、専門的な基準ではないので、正しい方向への突き出しを探しています。
私は現在、ユーザーの名前/住所/メールアドレスなどを1つのテーブルセットに収集し、他の個人情報を別のテーブルセットに収集するWebアプリを設計しています。これらは最も自然に1つのデータベースに存在しますが、私はユーザーの連絡先情報を別のサーバー上の1つのデータベースに分割し、他のすべての情報を別のデータベース/サーバーに分割することを検討してきました。理論では、ハッカーは両方のシステムを破壊する必要があります。非常に便利なものを手に入れるために。
私は数週間何度も検索を繰り返しましたが、これまでこのタイプのデザインについてはあまり議論されていません。これは一般的に行われますか？やり過ぎですか？それにアプローチするための設計方法はありますか、それとも私はそれをすべて自分で転がす必要がありますか？
データベースの分割は正当なセキュリティ対策ですか？これは、このアプローチはおそらくやり過ぎだと言っていると思います。
間違っているように見える私見。データを2つのDBに分割することにより、合理的なセキュリティ上の利益なしに複雑さが増すだけです。
ここでデータ暗号化が使えると思います。ユーザーの資格情報に基づいて暗号化キーを生成し、ユーザーの要求によって適切なデータを暗号化/復号化します。プライベートデータはそのユーザーにのみ表示する必要があるため、すべて問題ないはずです。
これはやり過ぎだと思う傾向があります。
この質問に対する私の答えを確認してください：2つのデータベース間でユーザーを共有する
データベース設計とデータアクセスのセキュリティ問題を別々に扱うことを忘れないでください。データアクセスセキュリティは、データベース設計において非論理的な選択につながるべきではありません。
以前に使用したアプローチは次のとおりです。
サーバー1：DBサーバー2：SC
DBは、一般の人がアクセスできるがSCにアクセスできないネットワークドメインにありますSCは、一般の人がアクセスできないがSCにアクセスできるネットワークドメインにあります
DBは、「本当に重要なもの」を含むすべての関連情報を保存した場所です。
指定された間隔（5秒使用）で、SCはDBをチェックして、監視する可能性のあるテーブル（ジョブまたはスケジュールされたタスクがある）の新しいレコードを確認し、重要な情報を暗号化します。
私はSQLServer2005を利用していて、2つのドメイン（プライベート（内部）とパブリック（クライアントアクセス用））で作業できましたが、共有したものは削除され（MSSQL専用の部分が削除されました）、簡略化されましたバージョン、少しの努力で、特に2つのデータベースを別々の物理マシンでホストできる場合は、mysqlで同様の何かを再作成することが可能だと思います。
多くの人がこれもやり過ぎだと思うでしょうが、このアイデアは実行されていました。それはより多くの費用がかかり、データ報告時間になるとより多くの作業を必要としますが、クライアントは満足していました。