Creating tables dynamically at runtime

Question

Is creating a table dynamically at runtime based on a user\'s interactions a good or bad thing for a web-app? (I\'m talking java, but question probably applies to more).

Answer 1

In general no, it's not a good idea. Normally whatever they would be creating would be records within a table.

But there are exceptions, for example if you are creating a hosting account for them, with the tables that they will then use personally.

Without giving more detail on your situation I can not give a better answer than that.

Answer 2

I am guessing you are doing something like this:

table_username(
id, 
userfield1, 
userfield2, 
ect...
)

One alternative would be to create a static table like so:

table_userfields(
id
userid
fieldname
fieldvalue
)

Only problem is that field value would probably have to be a large varchar.

But your approach is not wrong, it depends on your especific needs.

Answer 3

Tables are generally crucial to a user's interaction with the database. Consequently the absence of tables is fatal.

From this it follows, that creating tables on the fly, at runtime, is a bad practice because it means there is no guarantee of the user's experience. If a CREATE TABLE statement fails, for whatever reason, the user is stuffed.

So, it is q good idea to avoid business processes which rely on the runtime creation of tables. There are usually workarounds, except in very specific circumstances.

To a certain extent this depends on the flavour of RDBMS underpinning the application. For instance, Oracle has the concept of Global Temporary Tables which removes the call for dynamic table creation in almost all circumstances. But even without such fancy features, there are usually ways around it: for instance, adding A USERNAME column to a table and building a view on top of it which includes a WHERE clause filtering on USERNAME=USER.

Basically, DDL is expensive to execute, in terms of elapsed time and system resource. It creates transactional complexity. And it is risky: if it fails then the user cannot proceed. So for all these reasons it should be avoided.

Answer 4

As for SQL-Server, it's a very common practice to create temp-tables, table variables, use table-valued functions, etc. For example, it would be done in a database stored procedure that is called by your web application.

There is no hard and fast rule that I know if that says it's good or bad -- depends on the situation.

Answer 5

In general it's not a good idea unless your users are all good data modellers. Most users don't make good database designers. The average user won't think about things like making the right choice of data types and keys, designing coding schemes, analysing dependencies or applying normalization principles. Creating good data models is hard, which is why it tends to be left to specialists.