Hey there Paul.
I'm working with a price comparison website, and we have a similar
system going on. You see, products have 1+ prices, stored in a prices
table. We get prices daily from dealers, and handle historical prices
in a different table, just like Waylan said. The prices_hist table
holds the entire history for every product, and the "prices" table
just the current ones. On the front end of our app we only access the
"prices" table, leaving "prices_hist" just for report generation.
As to deletions (we call them discontinued offers), we have another
table called "prices_deleted" with fields idProducts, idDealers and a
timestamp. Every time a dealer stops selling a product, we delete it
from the 'prices' table, and insert a record to 'prices_deleted'. This
way, any history for the offer is maintained, but the snapshot table
("prices") stays current.
Sorry for the convoluted, incomplete text. I didn't have my morning
caffeine yet.
On 6/13/06, Paul Childs <[EMAIL PROTECTED]> wrote:
>
> Thanks for the input Waylan.
>
> It certainly gives me another angle on the solution.
>
> I have been digging into the docs again and it seems to me that Django
> is flexible enough to handle this without having to dive into the
> source.
>
> Of course it would be nice just to call the save() and delete() methods
> and everything would behave as listed in my first post.
>
> Cheers
>
>
> >
>
--
Carlos Yoder
http://carlitosyoder.blogspot.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---
