私は比較的小さなデータベースに取り組んでいます。合計 67 個のテーブルがあり、100 万を少し超えるレコードがあります。約254MBです。連携するアプリケーションは約 5 年間稼働しており、使用量は毎年 2 倍になっています。今年は 3 倍になると予測されていますが、これは 1 シーズンでデータベースのサイズがほぼ 2 倍になることを意味します。私の質問は、データベースを複数のデータベースに分割するのは悪い考えですか? 300 のクライアントがあるとすると、67 のテーブルを含む 300 の個別のデータベースが作成されますが、そのクライアントに関連するデータのみが含まれます。別のサーバーで実行できる内部統計以外に、データをまとめる理由はあまりありません。生涯でクライアント数が 10,000 を超えることはありません。
「マスターデータベース」スキーマに変更を加える必要がある場合、すべての「スレーブデータベース」全体で変更を複製する必要がある場合、このセットアップがどのような問題であるかがわかります
また、新しいクライアントが追加された場合、レプリケーションも困難になります。
コード レベルのアプリケーションは、このタイプのセットアップ用にほとんどセットアップされています。
不足しているものはありますか？これはひどい考えですか？
このデータベースは、将来のことを考えずに (私ではなく) 急いで作成したものであり、今は私の責任です。
正規化、フィールド タイプの監査、SQL の最適化、インデックス作成、サーバーのチューニングなど、やるべきことはたくさんあります。どんなフィードバックでも大歓迎です。