Question

I have a Database that has the following relations:

Transaction->Purchase->Item->Schedule

Transaction - self explanitory
Purchase - any purchase info that relates to the item being purchased (quantity, if the user purchases more than one item).  A given Transaction can have more than one Purchase_ID tied to it.
Item - Stores Item info and relates it to individual clients.
Schedule - determines the price of an item at a given time of day.

I need to execute a query that must select a series of values from Schedule based on if Transaction.TimeStamp is within a supplied date-range. The query needs to select a value from Schedule based on it’s primary key. The primary key is not traceable from transaction.

In order to resolve this issue, I have decided to create a table to link Transaction DIRECTLY to Schedule’s primary.

Recently I discovered Table Views – would this be an appropriate situation to make a table "view"? Or should I just create an ‘actual’ table TransactionSchedule?

transactionSchedule
Transaction_ID    Schedule_ID

My problem is I do not understand the specifics of when a table view is useful/what the benefits are.

Is having a individual table to Trace Transaction->Schedule overkill?

Really any general guidance with this problem would be much appreciated.

EDIT: this query is ONLY for retrieving data that has already been entered

–thanks

Answer 1

I would strongly urge you to copy the price from the schedule directly to Purchase as soon as you’re inserting that. That way, you have solved your problem, and at the same time, prevented from a different price being charged to the customer later on if you accidentally (or intentionally) change the schedule.

As for relating to the primary key of schedule, and this not being traceable from a transation: that is a sign of bad design. I mean, think about it – you have a timestamp in transaction, a schedule by definition is placed in time using a from and to timestamp – why can’t you relate them? AFAICS, primary key of schedule should be item_id, from_timestamp, to_timestamp

Assuming your schedule table has a from and to timestamp My query would be

SELECT     ..your columns..
FROM       Transaction t
INNER JOIN Purchase    p
ON         t.id        = p.transaction_id
INNER JOIN Item        i
ON         p.id        = i.purchase_id
INNER JOIN Schedule    s
ON         i.id        = s.item_id
AND        t.timestamp BETWEEN s.from_timestamp
                           AND s.to_timestamp

As for, should you use a view or not – really, it’s up to you. A view does not work better or worse than a query, the only difference is that the definition is stored in the database. The main advantages of that are

• people can reuse the definition without copying the query (and messing it up), the
• you can change the schema to some extent and hide that from the application provided you update the view accordingly (this latter advantage is often overestimated)