How do I define a 'flexible' relationship in my table?

I'm working on a large application, with tons of tables and a huge codebase. It's a system in which people have rights to use functionality X and/or functionality Y and/or functionality Z.

• Functionality X may be a user-related record in a table called dossiers.


• Functionality Y may be a user-related record in a table called portfolios.


• Functionality Z may be a user-related record in a table called api-couplings.

There's a bunch more but I'm trying to keep it straight-forward here. The problem I'm facing is that there's no overarching object called Product. A table in which we set the prices, the invoicing interval and what not. Functionalities X to Z are now granted to the user by an admin who just adds a record to those respective tables. That's gonna change; a user will be able to just select a product, pay and use it right away.

How do I setup this table flexibly? How do I refer to those individual tables? An option I do not want is this:

• id


• product_name


• price


• functionality_x_id (nullable)


• functionality_y_id (nullable)


• functionality_z_id (nullable)

That just feels wrong and will have me change the database table every time we add a new product type.

Something I did think about is something like this:

• id


• (...)


• functionality_table (functionality_x, functionality_y, functionality_z)


• functionality_record_id

That sounds way more flexible. I do lose my relational integrity, but I don't know if that's such a big issue.

Just to sum it up: in the end, the user has to select a product from which a record in any of the applicable tables will get created for him/her and thus grants the user privilege to that functionality.