MySQL-1つのデータベースに数百万のテーブルがあるのは良いことですか？
プロジェクト用に新しいMySQLデータベースを設計しました。プロジェクトでは、動的列を使用してテーブルを動的に作成する必要があります。したがって、単一のデータベースに無制限（数百万または数十億）のテーブルがある場合、データベースのパフォーマンスにどのような影響があるかを知りたいと思います。また、MySQLが単一のデータベースで作成できる最大テーブル数も知りたいです（InnoDBが400万テーブルを許可していることを確認できますが、「InnoDBとは何ですか？」はわかりません）。
ParentTable（静的） + ----------------------------------- --------------- + | ID | UserId | ParentName |説明|ステータス| + ------------------------------------------ -------- + ChildTable1（動的） + --------------------- + | ID | UserId |値| + --------------------- + ChildTable2（動的） + -------------------------------------- + | ID | UserId |名前|住所|ピンコード| + -------------------------------------- +
上記は、動的テーブルを使用してデータベースを設計した例にすぎません。親の詳細を静的テーブルに格納し、子データを格納するために、1つ以上の動的列を使用して動的にテーブルを作成しています。同じことを達成するための他の最良の方法はありますか？
更新1：
私は、ユーザーが列の数を選択し、各列に名前を定義するだけで、UIから独自のWebサービスを作成できるプロジェクトに取り組んでいます。今のところ、UserIdを参照してWebサービスごとに1つのテーブルを作成することを検討しています（上記の例を参照）。したがって、このアプローチでは、100万人のユーザーがいて、すべてのユーザーが10個のWebサービスを作成する場合、データベースに1,000万個のテーブルが作成されます。
この問題を解決するにはどうすればよいですか？
絶対違う。
各テーブルは、データベースを表すディレクトリ内の少なくとも1つのファイルを取ります。 OSのオーバーヘッドは重要です。百万ファイルのディレクトリで単一のファイル（テーブル）を見つけるというOSの努力は楽しいものではありません。等。
テーブルを動的に作成するのが一般的に貧弱な設計である場合。何百万ものものを生み出すのはひどいデザインです。
テーブル内の数百万、さらには数十億の行--thisは問題ありません。 「テーブル」の指定を置き換える追加の列がある--thisは「正しい」代替手段です。
アプリケーションについてさらに（具体的には「親」や「列」よりも）議論したい場合は、他の設計上の考慮事項について議論することができます。
同じ議論が何百万ものデータベースを持つことに当てはまります。