Question

I have a table that stores customer items. The table needs to reflect the following activities:

1. When a customer adds an item to his/her queue.
2. When the item is marked for shipping to the customer.
3. When the item actually ships.
4. When the item is marked for return by the customer.
5. When a return shipping label is created for the item.
6. When the item is received back from the customer.

The work flow will be as follows:

1. User(s) add item(s) to list.
2. Scheduled event marks items for shipping (corresponds to info point 2).
3. Employee creates shipping labels, then marks items as shipped (to info point 3)
   — Customer receives item, customer is happy.
4. Customer marks item for return.
5. Employee creates a shipping label the item.
6. Item gets picked up and returned.

A customer’s account should show the following:

1. Items in queue.
2. Items shipped.
3. Items marked for return (to allow customer to cancel if customer wants to keep the item for longer).

There is no value (in my scenario) for alerting the customer when an item has been marked for shipping on our end.

I initially thought of inheritance, but things have started to get out of handle quickly. I don’t know if I should have a subclass for each info point. Also, some things seem like they should not be in their own subclass (items marked for shipment, and for return, seem to be “in between” classes)

Should I be using inheritance and create a class for each information point? Or am I over complicating this?

Current schema

items
   - id
   - typeid (in queue, shipped, etc....)
   - userid
   - itemid
   - shippedat
   - returnedat

I’m using mySql, and anticipate the table to be large!

Answer 1

It sounds like you need a good way to separate the items themselves from the workflow which applies to them. One approach could be as follows:

• Define a table of items, minimally containing the userid and itemid
• Define a table of workflow states, minimally containing an id and a name (e.g. ‘processing’, ‘shipped’)
• Define a table linking items to workflow states, containing a foreign key to the item’s id and a foreign key to the state’s id, plus metadata applicable to the given item in the given state, such as when the state was entered or started/finished, who handled or checked-off the item in that state, etc.

Now, instead of having state-specific fields such as shippeddate and returneddate on the items table, you can find that data by joining a given item to its workflow (warning: pseudocode ahead!):

SELECT item.id, item.userid, item_workflow.completed_date AS returned_date
FROM item
JOIN item_workflow
JOIN workflow
WHERE workflow.state = 'Returned'

By joining items to their workflow and filtering for specific states, you can find items that are or are not in given states, and count items per state. So to address an example from your question:

There is no value (in my scenario) for
alerting the customer when an item has
been marked for shipping on our end.

In this schema, you search for a given item for a given user, and see if an item_workflow record exists for that item and the workflow state “Shipped”.