Efficiently storing different type of orders for a client entity [database schema]

Question

I've to design a database where I've a client entity and a client can place multiple type of orders (all differ with each other, but few fields are common among them like status, pricing, time etc). For example, he can place Order-A, Order-C, Order-F (from different forms). I'm confused how to cater different type of Orders.

This is what I've created so far.

Now I'm confused how to cater the fields that aren't common among order types. Should I create separate tables for each order type to save all different values? and add foreign key of all those tables to order table? It would be so complex. Whats the best way to do this?

Answer 1

The purist would say that you should create a separate table for each type of order, with the fields relevant to that order type. If there are fields that are common to all order types, these should be in a separate, common table. Then the tables with type-specific data should point to the "main" order table.

The opposite alternative is to put all the fields in one table, and set the ones not applicable to a given order type to null.

Which method you choose really depends on your data. Frankly, if I have 30 fields in an order record, and then one or two fields that only apply to some orders, I just throw them in the order table and let them be null when not applicable.

If you have many different order types and many different fields in different order types, creating separate tables can be a real beast. Who wants to manage 30 order tables? It also gets tricky when some fields are in more than one order type but not all.

Personally, I generally create one big table with all the fields and let some be null. This is usually the most practical. But you have to look at the nature of your data and your entities. If there are a small number of different order types and there are a large number of fields peculiar to each, it starts to make sense to make separate tables to keep them separate. It might be less confusing if there aren't bunches of null fields.