Followup to clarify. If you DON'T use a is_longdistance flag in the model, then you use a set of rules to determine if a number is long distance when you get the number out of the db.
You can avoid this by using a is_longdistance flag in the model, but you're going to have to do the same thing to determine whether or not to set the flag when you insert a number into the database. And you have the added pain of updating the db is these rules change, which you don't have to do if you just check for long-distance-ness upon retrieval. We could even argue that the flag is wasted space in the db. But if we get that nit picky, one could counter-argue that running the is-long-distance logic once upon insertion is more efficient than running it on each retrieval in a read-intensive system. However, I prefer and human-efficient practices over computer-efficient practices; computers get faster, humans don't. Thus, the cleanliness and (IMHO) elegance of simply doing the check upon retrieval and thereby avoiding potential manual updates to the db and introducing a new table field beats the alternative. Sorry again: huge tangent. Ross --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
