Best approach to avoid Too many columns and complexity in database design

Question

Inventory Items :

Paper Size 
-----
A0
A1
A2 
etc

Paper Weight 
------------
80gsm
150gsm etc

Paper mode
----------
 Colour
 Bw

Paper type
-----------
 glass
 silk
 normal

Tabdividers and tabdivider Type
--------

Binding and Binding Types
--

Laminate and laminate Types
--

Such Inventory items and these all needs to be stored in invoice table

How do you store them in Database using proper RDBMS.

As per my opinion for each list a master table and retrieval with JOINS. However this may be a little bit complex adding too many tables into the database.

This normalisation is having bit of problem when storing all this information against a Invoice. This is causing too many columns in invoice table.

Other way putting all of them into a one table with more columns and then each row will be a combination of them.. (hacking algorithm 4 list with 4 items over 24 records which will have reference ID).

Which one do you think the best and why!!

Answer 1

Your initial idea is correct. And anyone claiming that four tables is "a little bit complex" and/or "too many tables" shouldn't be doing database work. This is what RDBMS's are designed (and tuned) to do.

Each of these 4 items is an individual property of something so they can't simply be put, as is, into a table that merges them. As you had thought, you start with:

• PaperSize
• PaperWeight
• PaperMode
• PaperType

These are lookup tables and hence should have non-auto-incrementing ID fields.

These will be used as Foreign Key fields for the main paper-based entities.

Or if they can only exist in certain combinations, then there would need to be a relationship table to capture/manage what those valid combinations are. But those four paper "properties" would still be separate tables that Foreign Key to the relationship table. Some people would put an separate ID field on that relationship table to uniquely identify the combination via a single value. Personally, I wouldn't do that unless there was a technical requirement such as Replication (or some other process/feature) that required that each table had a single-field key. Instead, I would just make the PK out of the four ID fields that point to those paper "property" lookup tables. Then those four fields would still go into any paper-based entities. At that point the main paper entity tables would look about the same as they would if there wasn't the relationship table, the difference being that instead of having 4 FKs of a single ID field each, one to each of the paper "property" tables, there would be a single FK of 4 ID fields pointing back to the PK of the relationship table.

Why not jam everything into a single table? Because:

• It defeats the purpose of using a Relational Database Management System to flatten out the data into a non-relational structure.
• It is harder to grow that structure over time
• It makes finding all paper entities of a particular property clunkier
• It makes finding all paper entities of a particular property slower / less efficient
• maybe other reasons?

EDIT:
Regarding the new info (eg Invoice Table, etc) that wasn't in the question when I was writing the above, that should be abstracted via a Product/Inventory table that would capture these combinations. That is what I was referring to as the main paper entities. The Invoice table would simply refer to a ProductID/InventoryID (just as an example) and the Product/Inventory table would have these paper property IDs. I don't see why these properties would be in an Invoice table.

EDIT2:
Regarding the IDs of the "property" lookup tables, one reason that they should not be auto-incrementing is that their values should be taken from Enums in the app layer. These lookup tables are just a means of providing a "data dictionary" so that the database layer can have insight into what these values mean.