Flexible database design for an inventory system

Question

I have to build an inventory management system for my school and this is the problem that I'm facing:

There are multiple types of equipment that I have to store in my system:

Computers, Printers, Cartridges, Projectors, Mouses, Keyboards etc.

And there is some common data about each item, regardless it's type:

TEMSID (like a barcode), SerialNumber, PurchaseDate, RegisterDate and other, see item entity for more.

Also, each item type has it's specific fields that have to be stored.

This is how I am going to deal with it, however I'm not sure about it:

1. [item] table stores common data
2. [item] table has one to one relationships with other tables which store more details about specific items.
3. Repetitive data (Manufacturer, Model, Resolution etc.) is stored in other tables [itemType] to reduce redundancy.

Ignore those FK IDs from item table

---

I fell like it is a bad design.

If there is another more efficient solution, I'm ready to start designing from scratch. Thank you in advance!

Answer 1

Ask yourself: what happens, if the school gets an item, for which you don't have any table (fe like Printer and PrinterType ) in your database? And if this can happen often? Then you have to add new tables to the database each time.

On the other hand, you have type specific properties, but yet they can be common, like model or color .

If I were you, I would make a dynamic system, which means, the administrator/user can add any item (device) type and can add any properties to it.

I would design the db like this:

We have device types like printer, projector, etc. Then we have our devices table with the basic data and connected to the devicetypes table. Then we have a properties table, in which we hold the other properties of all the device types (one property only once, no redundancy). And finally, we have a propvalues table, where we store the different property values of each device.

F. e. in the above example, the device with id: 1 has two properties (model and color) with the values hp and true .

With this design, the user/administrator can manage as many properties as many he want.

One special thing: the value field should be fe a string field, because it can hold values like numbers, string, dates, etc. And in the view you have to cast this value depending on the datatype .

And if you have to manage compatibility data too, of course you can do it more generic. But maybe this should be a homework:-)