Hi Rajesh, Certainly, best practices are subject to your goals: code maintainability, storage efficiency, execution efficiency, etc.
I agree, there are times when it makes sense to store calculated values in a database. I would argue, however, that this inhibits scalability. As a system grows, the potential for inconsistencies due to this redundant data also grows. We have this issue at my current job right now. Our systems have grown organically over five years and we have various pools of redundant data that have been the sources of some scaling issues. Ross On Jul 2, 2:27 pm, Rajesh Dhawan <[EMAIL PROTECTED]> wrote: > Hi Ross, > > > > > I would disagree here. The database should only be used to store raw > > data; the database should not know anything about this data (the > > database should not be "smart"). > > > Determining whether or not a number qualifies as "long distance" is a > > job for the domain / controller / view layer (pick your jargon). > > > Here's why. Suppose the company moves, or the geographical scope of > > one area code is changed. Now you have a different set of rules that > > determine what qualifies a number as being "long distance." Would you > > rather change the rule with one line of code in your view, or > > construct and run some SQL that finds and updated all matching phone > > numbers? (Note: this is meant to be a rhetorical question but could > > very well be debated.) > > > Sorry for the tangent. I'm a stickler for best practices. > > That's fair...and although, you meant that as a rhetorical question, I > would indeed debate that and would further argue with your definition > of what constitutes best practices as implied by your post. > > Best practices don't exist in one dimension and they are not written > in stone. You can have best practices for high performance, highly > scalable applications that are different from best practices for > "regular" applications. Today's scalability needs demand that > developers keep an open mind on what's best for the application and > it's performance/scalability requirements. Most of the time, this is > not a problem as theory usually converges with practice for a lot of > applications. But not for all. > > When, for example, a regex based query is very expensive and your app > has many places where it wants to pull up phone numbers based on their > "is_long_distance" value, it certainly makes sense to store this > attribute in a precomputed form and refreshed it in a batch > computation if/when the rules for it change at all in future. > > Another example, if you have a model with a purchase order with child > items that represent each purchased item, it does make sense to store > the order total in the purchase order master record, even though you > could derive it from the sum of individual item totals every time you > need it. > > -Rajesh D --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
