0

ユーザーが任意の数の Web フォームを作成できるアプリケーションを構築しています。フォームは幅広いトピックを対象とし、あらゆる種類のフィールドを含むことができ、任意の数のサブフォームに分割されます。

これが正規化の問題にならないように、私のアプリケーションはサブフォームのテーブルを動的に生成します。エンド アーキテクチャは次のようになります (簡略化)。

/* 静的テーブル - 階層レベル 1 */
[ProjectTable]
project_id (KEY, AUTO INC), , project_name

/* 静的テーブル - 階層レベル 2 */
[RegistrationTable]
project_id (PARENT ID), registration_id (KEY, AUTO INC), registration_date

/* 動的テーブル - 階層レベル 3 */
[RegistrationSubTable_xxxxxxxx]
registration_id (PARENT ID), firstname, lastname, email

/*動的テーブル - 階層レベル 3 */
[TRegistrationSubTable_yyyyyyyy]
registration_id (PARENT ID), book_title

（これが理解できることを願っています:)

私の懸念は、動的テーブルの数が際限なく増加し、数年で数万に達することです。これは SQL (現在は MS SQL) に問題を引き起こしますか?

私が考えていない警告はありますか？

4

1 に答える 1

0

このトピックmaximum-number-number-of-workable-tablesが私の質問に答えていることがわかりました。

要するに、パフォーマンス ヒットが 10,000 を超えるテーブルで発生することはありません。大きなテーブルが少ないよりも、小さなテーブルがたくさんある方が、パフォーマンスが向上します。問題は、それらを照会して管理することです。私の場合、私のアプリケーションはすでにそれを行っているので、これは問題ではありません。

于 2013-07-20T17:12:43.257 に答える