Pathologically Eclectic Rubbish Lister | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
This is an interesting post. I agree with the second and third issues you bring up (tuning and task division), although I think that in many applications the third issue isn't sizable since it's the same developer with a different hat on :-) But you're focusing on large-scale applications so I understand. Regarding the first issue: I'm curious if you've measured the time needed to build the queries using the methods you describe here, or others more complicated. I like the general concept behind generating SQL statements beforehand, particularly for queries that rely on multiple tables, because it's easier to debug and to test. However, this seems to conflict with the desire of many users to perform ad-hoc queries, even if constrained by a simple web form. In cases like this, do you think it's a good idea to generate all the queries beforehand? This would seem to be a query-management nightmare since you have to account for every combination of criteria. This might lead to a hybrid system where often-used queries are generated beforehand but ad-hoc queries are generated (partly at least) at run/request-time. I'm thinking of including something like this in SPOPS as it would add a new wrinkle to managing object relationships. Chris In reply to Re: Eliminating Dynamic SQL Generation with Decision Matrices for Tighter Large Scale Applications
by lachoy
|
|