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
-~----------~----~----~----~------~----~------~--~---

Reply via email to