Home/ Questions/Q 7600149
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T22:50:34+00:00

I’m developing an Asset management application. Looking through the excel tracker that was being

  • 0

I’m developing an Asset management application.

Looking through the excel tracker that was being used previously, I was able to identify some attributes that were common to all categories of assets (basically non-technical attributes such as Purchase Order No. , Warranty Info etc.) for which I think I will make a separate table.

But when storing technical-attributes, there are many categories of assets for which I need only one or two additional attributes to be stored.

Should a make a single table for all these attributes and store NULLs wherever applicable or should I make a separate table each category containing just the asset ID and the addition columns? Which approach is better/more pragmatic?

Is cluttering the database with too many tables ok? I have around 10 such categories.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There are 3 known approaches to this:

    Single table

    In this model, you have a single table with all known columns, and allow them to be null for types that don’t have that attribute. This gives you a simple database, and fairly simple SQL, but doesn’t allow support for common features that relational databases give you, like insisting on non-null columns for a data type, or creating unique indices where that makes sense.

    It also tends to lead to messy SQL, with developers forgetting over time what columns mean, so you could get a column being used for multiple purposes.

    It does make it easy to join to other tables – so if you have an asset and a purchase related to that asset, the “purchase” table joins to the “asset” table on “assetID”.

    Table per subtype

    In this case, you build a table for each subtype, and enforce the data characteristics of that subtype with not null, unique etc.

    This creates a clearer separation of subtypes, and is less likely to degrade into big ball of mud, but makes joins very hard – to join from “purchase” to “asset”, you have to know which table holds that particular asset.

    Common table for common fields, table per subtype

    In this model, you have a single table for the fields that are common between subtypes – you say you’ve identified this already – and have further tables for each subtype to store the unique attributes.

    This solves the joining problem between “asset” and “purchase”, keeps the data pretty self-describing.

    It does mean client logic needs to implement the “join asset_master to asset_subtype” issue.

    I prefer option 3 – it’s the best trade-off between maintainability and managability.

    • 0