Re: 3vl 2vl and NULL

FrankHamersley wrote:
> dawn wrote:

<snip>
> > 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.

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

<snip>
> 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.

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.

> > During all those years of companies working hard to get end-user
> > reporting, MV end-users were either churning out reports and ad hoc
> > queries or asking their VARs or IT shops for new ones and getting a
> > fast turn-around on their requests.
> >
> > [Anecdote: I moved from an IMS COBOL shop with a significant backlog
> > for reports to an MV shop with no backlog, zero, zip, for any
> > reporting. It was very enlightening.]
>
> No doubt - COBOL would not be my lang of choice however!

Nor mine. Yours would be?

> >>- is this an important additional phase in the design phase or is it
> >>simple to retrofit on demand?
> >
> > simple, but not something you typically pass to an end-user to do since
> > it adjusts the schema (which is descriptive and not prescriptive, so
> > the risk is to other queries).
>
> What happens to these view if cardinality is changed - perhaps even
> arbitrarily - are they "self healing" or do they require maintenance?

Self-healing. The top value in each list is on the first line, with subsequent values below it.

<snip>
> Does it get deployed in multi-tier apps much - the one I saw was single
> tier.

These days, most definitely. Since it has been around > 35 years, there is still a lot of green-screen out there.

<snip>
> >>Is it easy to dump (aka bcp out) to another (SQL?) environment for ad
> >>hoc queries, routine reporting or data warehousing?
> >
> > A techie would say that it is easy and I have advised and assisted in
> > such efforts many times, but find it not altogether satisfying. Once
> > you normalize the data, your solution is no better than the average SQL
> > implementation so you lose the charm (e.g. ease in working with
> > multiple 1:M's in queries) and have the added pain of such things as
> > switching from 2VL to 3VL, for example (equating a Pick null with a SQL
> > null does not typically work well). Those for whom I have recommended
> > this approach for their specific requirements have told me it is
> > working well for them, however.
>
> Is there no other way to leverage these BI products?

Most people do downloads into Excel and elsewhere. There is a lot of variety and creativity in how this is done, but nothing standardized. <snip>
> There are no silver bullets! It reminds me of a prediction that I made
> when I first started in IT. I suspect I would need a different job in
> about 5 years because at the rate IT was expanding by that time
> programme writing programmes would make me as a hacker redundant. Of
> course I was coding in ASM at the time and we had been exposed to
> Modula-2 plus reviewed the Ada spec in the course, and it seemed like a
> formality. Of course I was wrong - so I gave trying to predict and just
> look for empirical data - which is why I see the market share as
> confirming the RM over the MV.

I understand the reasons for choosing that metric, given the lack of others. It is surely an indicator of something, but...

> Anything that upsets this apple-cart is
> going to be novel, not a throwback - yikes, another prediction!

I agree. If there is a focus on development productivity, the next big thing in data models will look more like PICK (e.g. XML, JSON) than RM.  That's my prediction.

<snip>
> OK - I accept that RM forms are not always instantly appealing to a
> casual observer. However I still rate the solidity of its foundations
> as more than adequate compensation, and once it is under your skin (i.e.
> it all clicks) then you hardly even credit that a "problem" exists.

Yes, and familiarity is a reason to stick with something that works too. At an industry level, we have SQL under our skin.

<snip>

> 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

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

Cheers!. --dawn Received on Fri Feb 17 2006 - 15:26:11 CET