Re: 3vl 2vl and NULL
Date: Sat, 18 Feb 2006 09:24:52 GMT
Message-ID: <EJBJf.10907$yK1.919_at_news-server.bigpond.net.au>
dawn wrote:
> FrankHamersley wrote:
>>dawn wrote: >>> >>>Similarly, the query language can be used to get what is called a >>>select list or saved list of keys for the selection aspect of what to >>>udpate. >> >>So you actually save the list of targets?
>
> Typically only in memory, although for some analytical reporting a list
> might be saved much longer.
Akin to the SQL non dynamic cursor.
>>What happens in a TP >>environment where it is a moving feast?
>
> It is just a step to use set processing prior to looping, like doing a
> select then iterating through a result set, except that you have only
> the keys.
Yup - Cursors. Definitely a last resort in my arsenal of tricks.
>>OK - what is the risk profile of less experience people writing ad hoc >>stuff. Is it easy for them to generate run away trains in a view that >>takes a lot of compute to resolve or are there safety nets?
>
> In a test environment, you can do anything, including run-away
> processes, but it doesn't happen as often as with SQL since you don't
> do cartesian cross-products.
Yup - I am currently embedded in a Sybase ASE environment and I have oft wondered why there is no deadmans handle on queries that have run off. Of course they are easy to kill if you have the sa_role but sometimes they pollute the log in a big way.
> With PICK you write a query and call it good without any or not nearly
> as much tinkering to tune it. If a query could be more optimal, it is
> likely due to a virtual field running a stored procedure that is not
> optimized. So the "query people" are always right (an exaggeration)
> while they might need to request that a programmer tune a stored
> procedure that wasn't properly tested. In theory, once the vocabulary
> is there for a query, you don't need to know very much to write good
> queries. Help desk folks for a software company, for example, can
> query happily right and left with PICK and it was quite difficult for
> some of them to pick up the complexities (due in part to the power,
> I'll grant) of SQL for the same tasks.
I agree the modern SQL engines have some serious torque!
[..]
>>No doubt - COBOL would not be my lang of choice however!
>
> Nor mine. Yours would be?
Right now I am happily ensconced with Sybase ASE SQL stored procs. It is a fat server thin client treasury settlement system. It does the job very well.
[..]
>>Look closely at the world around you. I just recently saw a .Net crash >>panel on a customer facing cash register screen. The operator just >>shrugged and rebooted the app - no problem, what problem, nothing to >>see, move along!
>
> good anecdote
Thanks - sadly as a player, I can't but notice these for what they are, and there are lots of them. For instance Al Jazeera seems to be .Net - there have been a number of times jazzy crash dump screens are displayed before the load balancer notices the machine is wobbly. Ah well, if you can't make the system work, make the diagnostics look professional.
> <snip>
>
>>Thanks for being candid about Picks top 5 shortcomings - your >>co-conspirators prolly think you are related to Judas Iscariot by blood :-).
>
> I'm pretty much known as a straight shooter. I did realize that while
> trying to come up with my top 5 or even n issues, constraints and RI
> don't make the list. That's where many think RDBMS's have this big
> edge. In theory, perhaps, but I haven't seen that be any more of an
> issue in practice in PICK than in SQL shops, and less of an issue for
> maintenance purposes in PICK shops. You have to code, test, deploy
> however you do it. If the business changes in a PICK shop, the same
> developer can change the code and the constraints, often using the same
> language to do so. That means the developer has no external
> dependencies, and external dependencies cost in time and risk.
As long as you recognise "no external dependencies" can also be a risk - a different risk, but still requiring management nonetheless.
Cheers, Frank. Received on Sat Feb 18 2006 - 10:24:52 CET