Hi

On Fri, 07 Jan 2005 14:05:16 +1100, Helen Borrie <helebor@...>
wrote:

>
> At 08:12 PM 6/01/2005 -0500, you wrote:
>
>> > Your query for matching up inventory with pricing at receipt
>> > doesn't need the SKU table, at least on information supplied.
>> > A simple join between Inventory and SKU_Pricing, matching
>> > sku_number and receipt_date, will get it.
>>
>> Ah, there's the rub. This assumes that there will be a price change
>> every day.
>
> No, it assumes that your logic (trigger or application) will write a a
> corresponding SKU_Pricing record each time a unique combination of
> sku_number and date_received enters the Inventory table.
>
> This in turn presumes that your structure provides a way to constrain
> uniqueness on sku_number and date_received. That in turn presumes that a
> DATE type was the right choice



> (it will *never* happen that you get more
> than one inwards goods movement per sku_number per day).

Hmmm? *never*?

Helen, I am not sure here whether your reverence to *never* means it will
never happen, or if you were meaning to refer to the preceding DATE
presumption.

In the "real world" such instances can happen, though perhaps some
instances could be covered by the goods received app.

A large order of goods can be receieved from more than one supplier. The
same SKU different suppliers. Stock input from the same supplier being
enteredon a different day to that on which it was received and is
coincident with a "new" delivery. The app (or human) may need to
differentiate between the received date and the data entry date, or at
least the data entry operator needs to be aware of what to do in such
instances.


--
Regards

Peter

Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Outgoing emails scanned by Trendmicro Internet Security