Home/ Questions/Q 7614377
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T02:23:21+00:00

Consider we have a database that has a table, which is a record of

  • 0

Consider we have a database that has a table, which is a record of a sale. You sell both products and services, so you also have a product and service table.

Each sale can either be a product or a service, which leaves the options for designing the database to be something like the following:

  1. Add columns for each type, ie. add Service_id and Product_id to Invoice_Row, both columns of which are nullable. If they’re both null, it’s an ad-hoc charge not relating to anything, but if one of them is satisfied then it is a row relating to that type.

  2. Add a weird string/id based system, for instance: Type_table, Type_id. This would be a string/varchar and integer respectively, the former would contain for example ‘Service’, and the latter the id within the Service table. This is obviously loose coupling and horrible, but is a way of solving it so long as you’re only accessing the DB from code, as such.

  3. Abstract out the concept of “something that is chargeable” for with new tables, of which Product and Service now are an abstraction of, and on the Invoice_Row table you would link to something like ChargeableEntity_id. However, the ChargeableEntity table here would essentially be redundant as it too would need some way to link to an abstract “backend” table, which brings us all the way back around to the same problem.

Which way would you choose, or what are the other alternatives to solving this problem?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    What you are essentially asking is how to achieve polymorphism in a relational database. There are many approaches (as you yourself demonstrate) to this problem. One solution is to use “table per class” inheritance. In this setup, there will be a parent table (akin to your “chargeable item”) that contains a unique identifier and the fields that are common to both products and services. There will be two child tables, products and goods: Each will contain the unique identifier for that entity and the fields specific to it.

    One benefit to this approach over others is you don’t end up with one table with many nullable columns that essentially becomes a dumping ground to describe anything (“schema-less”).

    One downside is as your inheritance hierarchy grows, the number of joins needed to grab all the data for an entity also grows.

    • 0