次のデータベース設計には深刻な問題があると他の誰かから指摘されましたが、その理由を教えてもらえますか？
この問題を指摘した人は、すべてのデータを1つのテーブルにマージし、FKを使用してそれらを区別する必要があると言いましたが、次のステートメントがあります。
このようにデータベースを設計するのは悪い習慣ですか？なぜ？ありがとうございました。
それはあまり維持できないからです。
1）データベースにデータを追加するために、構造を変更する必要はありません。モデルでは、別の人を追加する必要がある場合は、新しいテーブル（または2つ）が必要になります。あなたはこれをする必要があるとは思わないかもしれませんが、私を信じてください。あなたはするであろう。
したがって、たとえば、アプリケーションに機能を追加して、データベースに新しいユーザーを追加するとします。この構造では、エンドユーザーに新しいテーブルを作成する権限を与える必要があり、セキュリティ上の問題が発生します。
2） DRYの原則に違反しています。つまり、同一の同じテーブル構造の複数のコピーを作成しています。これは、メンテナンスをお尻の痛みにします。
3）複数のユーザー間でのクエリは不必要に複雑になります。このDBモデルに対してクエリを作成する必要がある人に対して復讐する以外に、各ユーザーを個別のテーブルに分割する正当な理由はありません。
4）各ユーザーが多数の行を持っているためにパフォーマンスのために複数のテーブルに分割している場合は、車輪の再発明を行っています。使用しているRDBMSには、間違いなく、大きなテーブルを効率的にクエリできるインデックス機能があります。自社開発のハックは、大規模なデータを処理するためのプラットフォームのアプローチを上回ることはありません。
それ自体が悪いデザインだとは言えません。これは、リレーショナルデータベースが設計および最適化されるタイプの設計ではありません。
もちろん、あなたが言及したようにデータを保存することはできますが、多くの操作は簡単ではありません。例えば：
あなたが本当にこれをすることを気にしないならば。このタイプの構造により適したMongoDBなどの非リレーショナルデータベースを使用することをお勧めしますが、先に進んで、提案どおりにテーブルを作成してください。
リレーショナルデータベースを使用したい場合は、人ではなくタイプごとにデータを集約することで、新しい人を追加したりレポートを計算したりするときに多くの柔軟性が得られます。
500kの線は「それほど大きく」ないので、デザインを作成するときにサイズを気にする必要はありません。
これらのタイプの要件には、mongoDBのようなドキュメントベースのデータベースを使用することをお勧めします。