|
|
Posted by --CELKO-- on 04/04/06 05:55
>> So you have never tried to diagnose performance or bugs in code developed by
a third party using nested views then? <<
Yes, I have. The trick is to buidl VIEWs that look as if they are the
tables in an RDBMS that was meant for one group of users, to control
them with DCL, WITH CHECK OPTION and INSTEAD OF triggers.
>> Nested views are a maintanence nightmare and should be avoided at all cost. <<
Perhaps the way you write them :) What I saw was a well-constructed
sets of summary views set up for tricky accounting reporting rules.
Given the same set of account codes, the customer wanted to have VIEWs
for each country's laws about what was a deductable, taxable, etc.
(this year! - change teh those views next year)
Each VIEW could be changed to include a list of accounting codes that
would choke a moose if you had to have each and every programmer do it
by hand for each query.
The other advanrtage of VIEWs in other SQL products is that they will
be materialized and shared among sessions at run time, rather than
re-computed over and over.
>> The real trick is to think through what you are trying to do and design your
schema properly in the first place. <<
I agree with that, but then we are getting back to avoiding IDENTITY
for relational keys and putting correctness over speed.
Tony, you still do not think of the problem as a whole at the
enterprise level. You are working at the level of a single programmer
who sees only his narrow slice of the pie. When you stop being a grunt,
you will not make the same decisions.
Navigation:
[Reply to this message]
|