Q:

Valid approach to have SQL tables dynamically generated?

I'm building an application where the user may create any number of web forms. The forms will subject a wide range of topics and may contain all kinds of fields, devided into any number of sub forms.
In order for this to not become a normalization issue, my application generates tables for the sub forms dynamically. The end architecture may look something like this (simplified):
/* Static table - hierarchical level 1 */
[ProjectTable]
project_id (KEY, AUTO INC), , project_name
/* Static table - hierarchical level 2 */
[RegistrationTable]
project_id (PARENT ID), registration_id (KEY, AUTO INC), registration_date
/* Dynamic table - hierarchical level 3 */
[RegistrationSubTable_xxxxxxxx]
registration_id (PARENT ID), firstname, lastname, email
/*Dynamic table - hierarchical level 3 */
[TRegistrationSubTable_yyyyyyyy]
registration_id (PARENT ID), book_title
(I hope this is understandable :)
My concern is that the number of dynamic tables will grow indefinitely, reaching tens of thousands in a few years. Will this present a problem for SQL (Currently MS SQL)?
Are there any caveats I haven't thought of?

A:

I find that this topic maximum-number-of-workable-tables answers my question.
In short, it will not cause a performance hit to have >10k of tables, not even millions. It is better for performance to have many small tables then to have few huge table. The problem is to query and manage them. In my case, this is not a problem as my application is doing that for me already.

