Pick query languages compared to SQL

#61

dawn wrote:

Quote:

That is one point where there is an issue, I think. Let's say that I
wanted to become well-versed in jBASE and DB2, two products I have not
touched. Assuming I'm starting at about the same point with each
environment, I suspect it would take me much less time to become
proficient enough to do excellent work in jBASE than DB2. What do you
think?

I really don't know. Though I started with MV in the mid 80's and
continue to use it today in various forms, I didn't find it difficult
to learn RDBMS products like SQL Server, MySQL, PostgreSQL, Sybase, etc.

I've never looked at DB2, but it is probably more complicated than some
of those mentioned above. I suspect the monster DB to learn is Oracle.

Quote:

When it is harder to do, it is considered a more complex skill and
awarded for that.

Oh, but is that really the case? Are our applications priced on how
"hard" it was for us to create them, or the benefit they provide to the
customer?

If your multi-million dollar company is losing thousands of dollars a
day because the system is down and I come and fix it within 10 minutes,
what is that worth? Do I charge 10 minutes for my time or a fee based
on the benefit that you received?

Or if I develop a program in a month that will save you a million
dollars over the course of 1 year, what do I charge you for that
program?

Quote:

There might even be a direct
relationship between complexity of products and rates someone can
charge. If that is the case, it bolsters my claim that SQL DBMS's do
not provide the biggest bang for the buck in s/w development.

Ah, but who's "side" are you on? Bang for the buck might be great for
the customer, but how about the developer's bottom line?

I'm probably going to open a can of worms here, but this is one of the
reasons I do not like free "as in beer" software. I'm going to start
another thread on this, so please reply their.

--
Kevin Powick

#62

"murthi" <c_xyz_murthi (AT) seeing_xyz_green (DOT) net> wrote

Quote:

I must say that whenever I read about QM, it reassures me that maybe
there's a future for MV after all!

With regard to the sturm-und-drang on dictionaries, I suggest to Martin
that maybe he should invent a new Dict type that unambiguously defines a
data element (can't have more than 1 for an attriibute, for example) and
maybe enforce/validate this with a the cd-like verb. This would go a long
way towards data clarity at least. I guess all of use creating the dreaded
"tools" have done exactly this (the "global" dictionary). If it were
enforced in the database, we'd be a step ahead.

I have recently begun looking at QM docs. Quite good. In comparing with
Uv, I note that there's much more detail instead of a
cold description. I, for example, did not know that you could dereference
subroutine arguments by parenthesis ie:
call mysub(a,b, (c), d)
so the sub can't change them (I'd use ...,c:'',... ). Notable that QM docs
even mention dereferencing, UV and others let you figure it out.

And the extensions look good, tho' I must quibble about the odd syntax of
some BASIC extensions. And in the L type, a % sign could've been > ie
OTHER.FILE>OTHER.DICT may'been clearer. But then, I like quibbling.

Sometime soon we will be taking a hard look at QM, and I hope to post some
results.

Chandru Murthi

Chandru (and Kevin)-

You really should take a closer look at QM/openQM these things you write
about are handled in very elegant ways.

Kevin wrote in an earlier post in this thread -
<paste>
I would say one of the biggest disadvantages of AQL is the inabilty to
return a data set. You may have a wonderful set of dicts in a customer
file that has all sorts of neat translations and conversions, but when
it comes to using that information in a PICK BASIC program, the best
AQL can do for you is get you a set of keys. You must then write all
the code to access the various files to retrieve, display and/or update
that information

Also, outside of using the Pick EDitor, and UPdate processor - neither
of which should be unleased on the common end-user, the only way to
update information in MV files is via BASIC programs. The data
manipulation features of SQL are quite handy and certainly more
powerful than those available in AQL/GIRLS.
</paste>

QM supports what Martin calls a Trigger which can be applied to any
attribute (column.)
These can be executed on Read/Write/Delete commands attempted from
anywhere - Tcl, Basic... You would then make a call to a stand alone
program designed to test the requested action against any criteria you wish.

Furthermore, since you have total control, you can make it "Fail Gracefully"
rather than just croak as will happen in many SQL DBMSs. Even recording the
offending record for later examination and continuing with the rest of the
items that do not pose a problem.

Also, Kevin- If you have a need to get a complicated dict translation
processed in a program you might try Execute with CAPTURE, or (if too large)
then Write the Query result to a file and process it as a standard data set.
I have done both with great results.

Happy coding...

BFaux ;-)

PS- Dawn, I enjoy your posts in CDP, CDT, and your blog FWIW.

#63

B Faux wrote:

Quote:

PS- Dawn, I enjoy your posts in CDP, CDT, and your blog FWIW.

That's worth a lot to me (at least as much as the pennies I've received
from Simon). Thanks a bunch! --dawn

#64

Hi Chandru,

Quote:

I must say that whenever I read about QM, it reassures me that maybe there's
a future for MV after all!

And I hope that you _do_ take the time to look into it because I think
exactly that as well.

Quote:

With regard to the sturm-und-drang on dictionaries, I suggest to Martin that
maybe he should invent a new Dict type that unambiguously defines a data
element (can't have more than 1 for an attriibute, for example) and maybe
enforce/validate this with a the cd-like verb. This would go a long way
towards data clarity at least. I guess all of use creating the dreaded
"tools" have done exactly this (the "global" dictionary). If it were
enforced in the database, we'd be a step ahead.

This has been lightly discussed and some constructive discussion on the
topic would be helpful. Even something like an @OFFICIAL or @REAL
phrase would IMHO be helpful.

Some of the ability to return a data set came from my attempting to
emulate the mySQL interface in PHP4 and Dave's Python work. There were
some feelings that "we don't want to turn QM into just a backend" but I
think that some sort of official description in the dictionary would
not necessarily keep people from cutting their fingers off if they
really wanted to <g> For those who would like enforced integrity maybe
a config item could switch either way.

Quote:

I have recently begun looking at QM docs. Quite good. In comparing with Uv,
I note that there's much more detail instead of a
cold description. I, for example, did not know that you could dereference
subroutine arguments by parenthesis ie:
call mysub(a,b, (c), d)
so the sub can't change them (I'd use ...,c:'',... ). Notable that QM docs
even mention dereferencing, UV and others let you figure it out.

This system has impressed me again and again. Someone above mentioned
that trumpeting the ability to output in CSV format was silly because
MV should have done this 20 years ago ... I think that the people who
are doing something (Ladybridge) should be recognized for contributing
those "should haves".

An aside about Ladybridge's response and capability: I think that a
whole 20 minutes or so transpired between my sending Martin a link to
the RFC for the CSV MIME type and a return e-mail telling me
nonchalantly that he had implemented RFC compliant CSV for the next
release.

Quote:

And the extensions look good, tho' I must quibble about the odd syntax of
some BASIC extensions. And in the L type, a % sign could've been > ie
OTHER.FILE>OTHER.DICT may'been clearer. But then, I like quibbling.

Sometime soon we will be taking a hard look at QM, and I hope to post some
results.

Quibble away. The spirit of PICK, eh? Thanks for your input on this,
-Tom

#65

Goo'day, Tom,
On 8 Mar 2006 18:27:11 -0800, "Tom deL" <ted (AT) blackflute (DOT) com> wrote:

<snip>

Quote:

I've been there for some time. Reality ... what a concept, but I prefer
openQM. <g

Geez, I have been agreeing with Bruce altogether too often lately.

You'll be getting notes from me poor ol' mum soon, telling you, like
she told me, "to get a proper job".....

Regards,

Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

If it ain't broke, fix it until it is....

#66

Talking as a *developer* rathar than a Database Administrator, I would
suspect that moving from one Relational Database to another would be
relatively system.

Similarly, moving from one MV database to another isn't too difficult as a
developer..

However, if you know MV - migrating to developing in a RD would be difficult
first time you did it, and similarly the other way around.

Am I just stating the obvious?

Obviously, Database administrators tend to specialise in specific databases
because of the underlying complexity - but it's not necessary to know all
the complexity of the database to be able to develop in it.

Regards
Simon
"Kevin Powick" <nospam (AT) spamless (DOT) com> wrote

Quote:

dawn wrote:

That is one point where there is an issue, I think. Let's say that I
wanted to become well-versed in jBASE and DB2, two products I have not
touched. Assuming I'm starting at about the same point with each
environment, I suspect it would take me much less time to become
proficient enough to do excellent work in jBASE than DB2. What do you
think?

I really don't know. Though I started with MV in the mid 80's and
continue to use it today in various forms, I didn't find it difficult
to learn RDBMS products like SQL Server, MySQL, PostgreSQL, Sybase, etc.

I've never looked at DB2, but it is probably more complicated than some
of those mentioned above. I suspect the monster DB to learn is Oracle.

When it is harder to do, it is considered a more complex skill and
awarded for that.

Oh, but is that really the case? Are our applications priced on how
"hard" it was for us to create them, or the benefit they provide to the
customer?

If your multi-million dollar company is losing thousands of dollars a
day because the system is down and I come and fix it within 10 minutes,
what is that worth? Do I charge 10 minutes for my time or a fee based
on the benefit that you received?

Or if I develop a program in a month that will save you a million
dollars over the course of 1 year, what do I charge you for that
program?

There might even be a direct
relationship between complexity of products and rates someone can
charge. If that is the case, it bolsters my claim that SQL DBMS's do
not provide the biggest bang for the buck in s/w development.

Ah, but who's "side" are you on? Bang for the buck might be great for
the customer, but how about the developer's bottom line?

I'm probably going to open a can of worms here, but this is one of the
reasons I do not like free "as in beer" software. I'm going to start
another thread on this, so please reply their.

--
Kevin Powick

#67

murthi wrote:

Quote:

I must say that whenever I read about QM, it reassures me that maybe there's
a future for MV after all!

With regard to the sturm-und-drang on dictionaries, I suggest to Martin that
maybe he should invent a new Dict type that unambiguously defines a data
element (can't have more than 1 for an attriibute, for example) and maybe
enforce/validate this with a the cd-like verb. This would go a long way
towards data clarity at least. I guess all of use creating the dreaded
"tools" have done exactly this (the "global" dictionary). If it were
enforced in the database, we'd be a step ahead.

I suggested a way of doing that to Martin a while back, so there's a

good chance it might appear. I got a "light bulb going on" response
from him, but turning ideas into reality is a lot harder than having
the idea in the first place, so he could well have hit implementation
problems (or just not got round to it).

Just like in UV (and PI) you had the ability with distributed files to
check the key of any data being written to a file, I suggested you
could attach an integrity check to the file in the same way. Then you
wouldn't even need your "cd" command :-) - attach an integrity check to
the DICT and any attempt to save ambiguous dict items would suffer a
write failure :-)

Cheers,
Wol

#68

Kevin Powick wrote:

Quote:

Anthony.Youngman (AT) ECA-International (DOT) com wrote:

One can pay the same price in SQL systems - when the system FORCES you
to enter dud data simply because it expects something, and won't let
you tell it that the data doesn't even exist!

I think this, like in any system, is application/design related. A MV
program that won't let you bypass an input field nets the same result.

At least with the RI and field typing available in some RDMS, data
*can* be checked/verified at the database level, thus preventing a
"bad" application from really messing things up.

Yep. It's one of the things I'd like to add as an OPTION to MaVerick -
switch on RI if required.

Quote:

I like Pick/Relational to C/Pascal - the first of each pair gives you
enough rope to hang yourself, the second constrains you so much it's a
wonder you ever get any work done...

I guess it wouldn't surprise you to know that I really like working
with Pascal :-)

we've just ported from UniVerse to MS SQL
Server,

It might be interesting to hear the story behind that. Pros, cons,
issues, etc. Why not start a new thread and share?

Not a lot to share really. Management didn't invest in the UniVerse
system. Management blocked developer requests to improve the system.

Then Management decided we were going to be an MS-only house ...

No study of pros, cons or anything - "no one ever got fired for buying
Microsoft", and that was the start and end of the justification :-(

Quote:

Half the information that I NEED to frame my queries isn't actually
stored in the database

Not sure what you mean. Can you elaborate?

We calculate statistical data. Retail Price Index type stuff. So we

have "typical shopping basket"s, "shopper's nationality" and "country
where shopper is living". And we calculate our indices on all possible
combinations.

So, to give you a stupid example, we REALLY DO calculate the price a
British Expat would pay to buy a FarEastern-style basket of goods in
New York. That's not a problem when I'm asked to go to our customer
database and provide the indices that the customer wants - the customer
database will say "this company wants a Brit buying a British basket in
New York" or even "a Brit buying a european basket in New York".

But I regularly get requests that say something like "please get me all
baskets into Mexico". But they don't mean "all", they mean "all
sensible". So when I get the Mexico indices from our database it gives
me a Brit buying a Brit basket, a European basket, and a FarEastern
basket (plus any other regional baskets we may have defined). And
NOWHERE has anybody bothered to log the fact that Britain is not a Far
Eastern country, and buying a Far Eastern basket is not sensible.

It's things like that that I was getting at. It seems to be common with
relational databases, that they spend so much effort analysing the
immediate problem, that they miss the wider issue. Here it was our COL
database (the index database) provides all the COL information we might
ever want. The customer database tells us what our customers are
entitled to, and/or normally want. The trouble is, many of our
customers are entitled to a lot more than they normally want, and will
come to us with special requests. And then I end up in the situation
above, where if I ask the customer database for what they want it
doesn't include the special request, and if I ask the COL database it
gives me what they are entitled to which is far more than what they
want :-(

All made worse by the fact that they used outside contractors :-( who
didn't understand the business to start with :-(

Cheers,
Wol

#69

Kevin Powick wrote:

Quote:

dawn wrote:

That is one point where there is an issue, I think. Let's say that I
wanted to become well-versed in jBASE and DB2, two products I have not
touched. Assuming I'm starting at about the same point with each
environment, I suspect it would take me much less time to become
proficient enough to do excellent work in jBASE than DB2. What do you
think?

I really don't know. Though I started with MV in the mid 80's and
continue to use it today in various forms, I didn't find it difficult
to learn RDBMS products like SQL Server, MySQL, PostgreSQL, Sybase, etc.

I've never looked at DB2, but it is probably more complicated than some
of those mentioned above. I suspect the monster DB to learn is Oracle.

When it is harder to do, it is considered a more complex skill and
awarded for that.

Oh, but is that really the case? Are our applications priced on how
"hard" it was for us to create them, or the benefit they provide to the
customer?

When you actually look at the details, you'll probably find it is the
former!

Quote:

If your multi-million dollar company is losing thousands of dollars a
day because the system is down and I come and fix it within 10 minutes,
what is that worth? Do I charge 10 minutes for my time or a fee based
on the benefit that you received?

Or if I develop a program in a month that will save you a million
dollars over the course of 1 year, what do I charge you for that
program?

Who wrote the system that is down? Unfortunately, all too often, the
guy who screwed up writing it is the guy who is paid extra to fix it.
If you're fixing someone ELSE's system, then you're worth every penny.

As for developing a program in a month, what if I could develop the
equivalent in two weeks? Ask yourself this - who, in the real world, is
going to end up getting more? You, of course! But are you worth more
than me for taking twice as long?

Quote:

There might even be a direct
relationship between complexity of products and rates someone can
charge. If that is the case, it bolsters my claim that SQL DBMS's do
not provide the biggest bang for the buck in s/w development.

Ah, but who's "side" are you on? Bang for the buck might be great for
the customer, but how about the developer's bottom line?

At the end of the day, it's the customer that pays the developer's

bills. If you don't look after your customer's bottom line, he's not
going to be around to feed you tomorrow (equally, if you do too good a
job, he won't need you tomorrow! :-(

And, as I said in reponse to your "free software" thread, the majority
of software developers are actually a cost to the customer. He has
every incentive to reduce how much he pays you, and I'm sorry, but
that's the capitalist world we live in ...

Cheers,
Wol

#70

Anthony.Youngman (AT) ECA-International (DOT) com wrote:

Quote:

Who wrote the system that is down? Unfortunately, all too often, the
guy who screwed up writing it is the guy who is paid extra to fix it.

Interesting point. Is fixing bugs something that clients should pay
for as part of the development process?

Debugging is part of developing code, so I think the client pays for it
at one time or another. Either before the code is released, or when it
is in a live environment.

Ideally, I think most of us strive to produce bug-free code, but
sometimes bugs just don't show up until the system is stressed in a
live environment.

I think most people understand this and such bug-fixing is usually
covered by ongoing support contracts.

Quote:

the majority
of software developers are actually a cost to the customer. He has
every incentive to reduce how much he pays you, and I'm sorry, but
that's the capitalist world we live in ...

And as developers, we have every incentive to maximize our profits as
well. There must be give and take on both sides of the customer/vendor
relationship.

--
Kevin Powick