Modeling a ticket system based on a set of disparate kinds of tickets?

I'm working on a project that allows for the creation of "support tickets." These are not confined to something that needs fixing, however, so in a way they could more accurately be called "jobs."

For the frontend of the project, the tickets are to be created out of predefined "templates." I've listed three examples below:

• Removing a discontinued product(s) from our online storefronts. This

template would require information on which vendor the discontinued
product(s) belong to, which product(s) is/are discontinued, the
reasoning for the discontinuing.

• Resolving product upload errors. Information would need to be

provided on the upload's batch id, the number of errors needing
fixing, from which vendor the errors came from.

• Fixing a workstation. Information on the workstation number, what

the problem is, and the urgency are fields that would be required.

Of course, each kind of ticket would share common attributes like the name of the ticket (a short summary of the issue/assignment), the issuer's user_id, the deadline, whether or not it has been resolved, etc.

I am trying to model this system relationally, but I am not sure if it's appropriate. The biggest struggle I'm having is how I can model and relate the different "kinds" of tickets. This seems perfect for some kind of inheritance, but should this be stored in a relational database?

It has felt natural to try some sort of EAV model, but I've heard that this should be avoided like the plague (I don't know whether or not this is an accurate evaluation).

Here is a diagram of my current attempt:

I've included the rest of the relations in the image for context.

The accompanying (generic) SQL code as generated by SQLEditor:

```
CREATE TABLE actions
(
action_id INTEGER NOT NULL AUTO_INCREMENT UNIQUE,
name VARCHAR NOT NULL,
PRIMARY KEY (action_id)
);

CREATE TABLE departments
(
department_id INTEGER NOT NULL AUTO_INCREMENT UNIQUE,
name VARCHAR NOT NULL UNIQUE,
PRIMARY KEY (department_id)
)

You mentioned the term "template" in your description but don't use it in your design. So, first, you need table that lists all possible template types - template_type with id and name columns. As an example it may contains the following data:

Id    Name
 1    Removing a discontinued product(s) from online storefronts
 2    Resolving product upload error
 3    Fixing a workstation

Then you need storage for configuration of each template type - template. It contains records for each ticket_key which includes into particular template as well as reference to id column in template_type table. Now each particular ticket should have template_type_id column to reference to its template type.

And now, you can implement your authorization system by setting access rights for particular ticket_key in particular template.

EDIT: corrected according comment to the answer.

StackExchange Database Administrators Q#37366, answer score: 2