Hello Group,
I am not an experienced application designer and need your help.
I would like to discuss the structure of the project I am about to
rebuild.
Currently I am maintaing a service where users put their offers.
My example "Offer" model:
class OfferType(models.Model):
name = models.CharField(db_index=true, help_text="One word offer
type name")
name_desc = models.CharField()
name_long_desc = models.Textfield()
class City(models.Model):
name = models.CharField()
offer_type = models.ManyToManyField(OfferType, help_text="I need
to have only some cities available in specified offer_type form.")
class Offer(models.Model):
creator = models.ForeignKey(User)
creation_date = models.DateTime()
type = models.ForeginKey(OfferType)
trashed_at = models.DateTimeField()
finished = models.BooleanField()
city = models.ForeignKey(City)
other fields..
def is_new(self):
return creation_date < 2 days.. 3, or more (depending on offer
type)
def(other methods on object)
Till now all offers had the same fields (except of offer_type), so I
could use just one model.
Now I was asked to create a new type of offers which differ from
previous"Offer" model scheme.
There will still exist fields like "creator","creation_date",
"trashed_at", "finished". For some of them
the "is_new" condition will change (as stated above in the model).
In my views I have created views which point to specified offer type
(using /(?P<offer_type>\w+)/ in urls.
- display_all_offers
- display logged_user_offers
- search_offer
- view_offers_by( additional variable in urls. ?P<filter_field>\w+)
- create_offer
- offer_notifications (create notification rules, when offer appears,
sends email)
These are my considerations:
1. Use model inheritance, with "Offer" model as parent, then use
get_offer_form_for(offer_type), get_alter_form_for(offer_type) (or
even add offer_type to ModelClass form arguments, and put the logic
in
OfferForm, OfferAlertForm..
Pros:
- using one set of templates, views.py, forms.py (one app)
- can easily get all offers added by specified user, or at specified
amount of time..
- methods from parent class inherited?
cons:
- complex queries, each query at least on 2 tables (using JOINS) which
can act on performance
- app may become too complex
It's easy to create forms for adding, deleting offer.. and not easy to
create f.e. alert forms (different fields for offer_types) (actually,
I didn't come with the solution yet.. I would like to avoid creating
another alert model for each offer_type
2. Use abstract model Inheritance
Pros:
- queries with less JOINs
- using the same subset of templates
- app may become too complex
cons:
- can't get all offers by specified user (need to query x*offer_type
models) (it's not the big problem though and not so important)
- Need to write methods for every offer_type model separately (is_new,
and others.. even if there will be offer_types for which
expiration_date (is_new) is the same)
3. Use as many apps as offer_types)
pros:
- easier to maintain code
cons:
- copying lots,lots.. of code with similar logic
- changes must apply to all apps when adding new functionality..
- model structure doesn't differ much then using inheritance with
abstract=True..
Please correct me If I am wrong here with above considerations.
Everyday there are about 500 offers added. I am considerind moving
them to archive when they expire, so there should not be more then
500 .. 1000 offers when querying the table.
Using Django 1.0 with PostgreSQL.
How would you solve this design problem?
Thanks,
Robert
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---
