I think your question is mostly about table design for relational databases. The best design follows certain 'normalization' rules which ensure that information is kept once and only once to ensure integrity.
One table per item is certainly the wrong approach, as it will mean that you constantly have to change your database design to add items. A simple approach would be to have one table Items containing your items with all the relevant information (model, color, image, whatever you have). Then have a second table ItemPrices containing the price, time stamp and a foreign key to the Items table. An item.itemprices_set.all() in Django would get you all the prices for an item or you could filter for the most recent timestamp which would give you the current price. (The right design depends a bit on how important your past prices are compared to the current one), Have a look at one-to-many relationships in the Django documentation on http://www.djangoproject.com/documentation/db-api/ Once you have your Django model a python mangage.py sql will print out the sql Django expects if you need to adapt an existing database. HTH Ludwig 2008/9/4 David <[EMAIL PROTECTED]> > > Thanks for your reply, I haven't described the tables (or how) as I am > still trying to rationalise the best approach. Perhaps if I describe > to you want I want to do you'll see the best approach. > > Consider the case of a shop (for example) and items can be added to > the shop and their prices continually updated with a date stamp > (although you want to keep the historical prices), but if an item is > discontinued you do not want to remove its historical prices from the > table. > > My thinking (which could be wrong) was to generate a table per item > but if I am understanding your suggestion correctly one can add an > extra column within an existing table (and then I assume have another > table for date stamps, or two columns in the original table). In > either case, how would you go about adding columns and have django > deal with the change in table structure? > > Thanks, > David > > On Sep 3, 10:25 pm, Ned Batchelder <[EMAIL PROTECTED]> wrote: > > Django won't deal well with dynamically-generated tables, as it maps > > classes to tables, so you'd need dynamically-generated classes, and then > > code that could use those classes. This is the way all ORMs work. > > > > You haven't described these tables, or how (or even why) they are being > > generated. If they all have the same schema, then "dynamically > > generated tables" means you are going against the grain of a relational > > database. You will likely be much happier adding one more column to > > your table and using one statically defined table to hold all of the > data. > > > > --Ned.http://nedbatchelder.com > > > > > > > > David wrote: > > > Hi, > > > > > I am still learning django and was wondering on the following > > > question > > > as to how one would go about doing it in the django framework: > > > If I have a cron job that dynamically creates new tables that are > > > spawned out of new entries in a main table. For example Table > > > 'Global' > > > has a new entry 'A' this will generate a new Table called 'A' (and > > > Table 'A' will be linked to its entry in 'Global') etc. > > > How would one go about having django interact with this (or perhaps > > > create)? actually, this leads to another question - can one have > > > similar procedures to cron job's working with django? such as regular > > > maintenance or in my case creation of tables due to an external > > > factor. > > > > > thanks > > > David > > > > -- > > Ned Batchelder,http://nedbatchelder.com > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
