G
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).
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).