Creating new tables dynamically based on user input is usually not a good idea. If the basic structure of forms changes, all the dynamically created tables will need to be updated to include new columns or have old ones removed, and this can cause maintenance headaches. Then there’s problem of knowing which table to query (which will probably lead to dynamic SQL which opens up all new problems). And there’s probably performance problems too, but I’m not certain how bad that would be. Also, a table is usually used to represent a type of entity (such as “web form”) rather than having copies of the same table for each new instance of the same entity.

I’d suggest a single table for the forms. You’ll need an identifier on each form to identify whose form it is:

forms
-----
  id (PK)
  name
  owner_id (FK to users.id)
  (other fields)

form_elements
-------------
  id (PK)
  form_id (FK to forms.id)
  element_type_id (FK to element_types.id)
  caption
  (other fields)

element_types
-------------
  id (PK)
  name

element_list_values
-------------------
  id (PK)
  element_id (FK to form_elements.id)
  name
  value
  (other fields??)

Your web application can let users create forms which will be saved in the forms tables, with a reference to the user that created (assuming that you are tracking users as proper entities). The form is populated with form_elements that reference the forms table so they know which form they belong to, and the element_types so they know which type they are. element_types will store a static (mostly) list of different elements a form can have. Types could be: “text_field”, “drop_down_list”, “radio_buttons”, “checkbox”. For types such as “drop_down_list” and “radio_buttons”, you’ll need an extra table, maybe called element_list_values to store the possible options for the lists that these elements normally have.