Creation of tables at runtime

Question

Hi,
In our project, requirement is such that, customer can create a form definition from UI. He can define all columns for the form, it's datatype, constraints etc. Based on that information, then they can do data entry in that form. So, until runtime, we don't know the structure of the form and each form can be unique so we cannot pre-define any columns. We need to have database tables to store the data they enter.
We evaluated few options and we are leaning towards creating the table at runtime based on the form definition. There can be thousands of records for each form and we also need some calculations on this data. So, creating one table for each form seems to be a better fit but creating tables at runtime is discouraged, in general. I would like to know opinion on this option.
(if any specific details are required then I can post it)
Thank you for your time.

Answer 1

1005222 wrote:
In our project, requirement is such that, customer can create a form definition from UI. He can define all columns for the form, it's datatype, constraints etc. Based on that information, then they can do data entry in that form. So, until runtime, we don't know the structure of the form and each form can be unique so we cannot pre-define any columns. We need to have database tables to store the data they enter.Wrong. What the customer wants to is use the database directly - as creating tables and constraints and the like is exactly that. Using database DDL to define objects. The database also has a data dictionary (a very comprehensive one at that). So there is no need for you to insert another layer in-between the customer and the database that contains meta data and what not.
The only automation required is to have the customer enter the definition in a template/form, and for your code to translate this directly to a DDL. Exactly the same as what DBCA does when you create a new database and click the icon to define a new tablespace. A form pops up. You enter the attributes and name of the tablespace. The s/w turns that into a DDL statement.
If you want some kind of auditing, then log the DML created to an audit/log table, after constructing it. The s/w can also log the result (error or success) of that DML's execution.
This should be the extent of your s/w's functionality. To create additional user/custom meta data tables, would be just plain silly IMO. Use the Oracle dictionary. Use the COMMENT command to add to the meta data. Do not reinvent Oracle's meta data layer.
We evaluated few options and we are leaning towards creating the table at runtime based on the form definition. There can be thousands of records for each form and we also need some calculations on this data. So, creating one table for each form seems to be a better fit but creating tables at runtime is discouraged, in general. I would like to know opinion on this option.I agree that this approach is questionable - as you just as well can give the customer a copy of SQL-Developer instead to use. As that would be the most appropriate tool for someone who insists on creating and maintaining their own data objects in Oracle.
The key issue IMO is, if this is the approach decided on, to use Oracle as a database. And not invent your own custom database layer with meta data and have the user using that, while your code then "maps/translates" that to the real tables and objects in the database.