On Jul 2, 5:33 pm, Ross Dakin <[EMAIL PROTECTED]> wrote: > 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. Sure. Now what if the set of rules you need to use don't fit in "naturally" into the RDBMS layer? For example, a regex search in a field is, obviously, not the most efficient way to determine long distance-ness of a phone number record if you have say a million phone numbers. RegEx searches tend to be CPU-intensive and having to perform them over and over to determine the value of an important/frequently needed attribute is not necessarily the best design choice. > > 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. Yes, but you would need to do it only once per record insert/update. It's typical for most systems to perform far more DB record retrievals than DB record updates. So, a modestly expensive operation when repeated millions of times does call out for a proper design choice (compute on retrieval vs. compute on save.) > 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. Again, the pain is relative to the design of the application and DB. You could, for example, have a DB trigger update that flag for you transparently. You could, for example, also establish an architecture where DB updates go through a stored procedure or a framework's ORM layer and hook in any pre-computations there. > > We could even argue that the flag is wasted space in the db. Arguing that would be wasted usenet space in today's day and age :) > > 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. You would be right if this were a simple check that's naturally efficient in SQL. But a regex check doesn't fall in that category especially a regex check that has many different OR conditions and especially one that might be run over millions of phone records. > > Sorry again: huge tangent. I don't think it is. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
