Home/ Questions/Q 3333754
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T23:49:52+00:00

I design the tables as below for the system which looks like a package

  • 0

I design the tables as below for the system
which looks like a package delivering system.

For example, after user received the package, postman should record in system,
and the state(history table) is “delivered”,and operator is this postman,
the current state(state table) is of course “delivered”

history table:
+---------------+--------------------------+
|   Field       |        Desc              |
+---------------+--------------------------+
|    id         |    PRIMARY KEY           |
+---------------+--------------------------+
|    package_id |    package_tacking_id    |
+---------------+--------------------------+
|    state      |     package_state        |  
+---------------+--------------------------+      
|    operators  |    operators             |
+---------------+--------------------------+
|    create_time|    create_time           |
+---------------+--------------------------+   

state table:
+---------------+--------------------------+
|   Field       |        Desc              |
+---------------+--------------------------+
|    id         |    PRIMARY KEY           |
+---------------+--------------------------+ 
|   package_id  |    package_tacking_id    |
+---------------+--------------------------+
|    state      |    latest_package_state  |
+---------------+--------------------------+

Above is just the basic information to record, some other information(
like invoice, destination,…) should be recorded as well.
But there are different service types like s1 and s2, for s1 it is not needed
to record invoice but s1 need, and maybe s1 need some other information to record
(like the tel of end user).

After all, at delivering way stations there are additional information to record,
and for different service type the information type is different.

My questions:

  1. For different service type, shall I need to declare different tables(option A) or just
    one big table which can record all information for all types(option B)?
  2. If option A, since the basic information above is MUST, how
    can prevent from declaring there duplicate fields in different tables?
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I have no completed answer for your issue, but you may try inheritance pattern in table design.

    Service Table(service) : used to put common or not-null columns in all kinds of services.
sv_id - internal key(PK)
sv_data_1, sv_data_2, ...

    Service 1 Table : dedicated attributes to service 1 and 'inherited from service'.
sv1_id - internal key(PK) and foreign key to service(sv_id)
sv1_data_1, sv1_data_2, ...

    And so on to other dedicated service table…

    1. For convenience(and performance), adding a ‘sv_type’ column to represent the exact ‘sub-type table’ of servcie if you need to list all kinds of services.
    2. Otherwise, just using ‘inner join’ to get the specific type of service.

    Although we need to use ‘join’ to get all attributes of a specific type of service, but the schema showed would construct the ‘null-free’ solution for your issue.

    If you care about the performance issue, there is one positive thing: joining tables for a specific type of service is accomplished with two primary keys.

    More about performance, you can create cached tables with joined base tables when you need speedier query and don’t worry about null-error and type-error issue of services.

    • 0