Defining data items via a data definition table?

[Guest]

I'm working with a ticket writer program.
Currently, there is one main ticket table which contains all the data for a
ticket.
There is now a need for tickets of certain types to require extra
information. There could potentially be many different ticket types which
require many different lists of information. I want the solution to be
table-driven so it can be maintained by the users.
What I envisage (and want input on) is a table of 'types' which identifies a
ticket type and a table of 'type data' which lists all extra data items
needed for the type.
The data will be saved in a table that refers back to the 'type', 'type data
item' and the ticket number. For the UI, I envisage a 2 column form that
lists the data descriptions to the left and has input fields to the right.
Anyone done anything like this?
The extra information will need to be reported on, so I will have to join it
to the main ticket table data which it seems will be complex given my
envisaged design (where the data item is identified by a column's value).

 

[Guest]

I've done things with similar issues. I always look for available
shortcuts / simplifications. (also because I'm not a heavy duty progamming
jock). If the application is focused on printing tickets, one possibility is
to define the fields by the printing place on the ticket rather than it's
underlying information definition.

 

[Guest]

thanks for the response.
the data items have to be captured into the database and available for
viewing and/or updating. they will also be used in reporting. so the data
storage mechanism is critical to the entire process.