Re: 3vl 2vl and NULL

dawn wrote:
Frank Hamersley wrote:
dawn wrote:
Frank Hamersley wrote:
dawn wrote:
<snip>
For my benefit can you identify the top 5 (in your opinion)?

1) The query language has no corresponding update language ever put
into production

Was there a plan to do so, or was PickBasic deemed capable enough?

Chandru (who has posted in this forum) wrote an update processor in the
early 70's that wasn't quite ready for prime time when Pick joined
forces with Microdata, so that software was not bundled with the
system. I don't know the whole story, but it appears that the project
was picked up in the 80's and was a pet project for *** Pick. There
are interactive tools, but no language-based set processing update
processors that I have found in my look over the MV landscape. I would
guess that one reason this was never completed or implemented was that
DataBASIC is a very full-featured language that satisfied the primary
requirements for developers, so there was no outcry (and still isn't).

Fair enough - maybe one day, maybe not!

So
every update is a programme? Thats not so bad if you have a "copy deck"
of standard templates and access/update methods.

Yes. Often CRUD services are written (SOAs are not a new concept ;-).

Of course with SQL
large portions of the query statement can be used in forming the update.

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? What happens in a TP environment where it is a moving feast?

2) The DataBASIC language often used in MV solutions
<snip>
So is C :-). What sort of library support does it offer?

I'm not a DataBASIC programmer, so maybe someone else will pick this
up.
<snip>
How do you predict all of the required logical views for ad hoc queries

That is a significant issue. Most sites don't predict, but react to
requests throughout the development process and after an application is
live, adding in virtual fields (derived data or path to attributes in
other files) as needed. At one site I worked, we hired student
employees to work a few hours a week to add virtual fields as requested
and if any report was too complex for end-users, then they would write
the report for them too.

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?

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!

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

4) There is no standard across vendors for a data source definition.
There is no standard for client-server connectivity. This gives third
parties the floor to write products like the jBASE mv.NET product that
works with many different flavors of MV.

So each programme instance latches on to the files directly - no daemon
request-response mechanism possible?

Each vendor has their own daemon approach for client-server, but these
are not standardized. VARs and 3rd parties do not write
MV-database-independent applications as often as they do in the SQL
world.

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

5) Third-party products for Business Intelligence and practically
everything else speak ODBC

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

I'm not sure these are my top 5, but they are 5 of the top issues I
have with MV.

Ouch - in my current business space, any of those would hurt like
amputation without anaesthetic!

Yup, there are pros and cons with SQL products and with non-SQL
products. In spite of these issues and others, MV typically still
seems to be a bigger bang for the buck solution for companies. Just as
people defend the RM while having problems with SQL, I think the MV
data model has a simple elegance and something like it could help the
s/w dev industry reduce costs and improve products in a big way. JSON
and XML are both "something like it" in different ways but do not carry
successfully into the persistence layer (yet?), while MV has a
significant (even if invisible, bz it is sold through VARs) installed
base.

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. Anything that upsets this apple-cart is going to be novel, not a throwback - yikes, another prediction!

When talking about data modeling, however, that is one area
where I cannot leave MV behind unless I can find a better data model.

<snip>

Even if your data model ambitions were accepted, I doubt I could cop any
of your top 5 to get that.

I'm not aiming to convince a current SQL-DBMS customer to adopt an MV
database, even if they would be well-served. I'm trying to convince
"the industry" to adopt more flexible (dare I say "agile") data models
and related tools. That is why I smiled when Oracle bought a non-RDBMS
product line with Berkeley DB and DB-XML and when IBM bought U2

I wouldn't ascribe too much to moves by marketing types.

(although they didn't know what they had at first). I don't think you
can easily transition an RDBMS to where it needs to be (backward
compatibility issues) so these companies need to start with something
other than the RM (i.e. ditching the Information Principle) and SQL and
move forward from there on some front.

Good luck to them - hey why not bet on red and black, since 70 to 80% (anecdotally) of project sinks without much trace why not do a Chaney and spray shot all around!

OK - but to summarise our discussion to date your problem with the RM is
the inherent constraints prevent you from having a visually aligned data
model that correlates exactly with the user view of the data model as
particularly expressed by the UI.

Is this a (relatively) succinct statement of your view?

I don't think so because I think your defs sound different from mine.

Thats why I restated in just 4 lines - on rereading them and my next
para is it the nub of your opinion?

By "correlates exactly with the user view" it sounds like you think I
want the data from a single screen to be stored as a single entity or
something like that. I would not look for the logical data model of UI
screen to be identical to the logical data model of the database.
Surely one screen might collect data that updates multiple entities.

I didn't (except for the need of brevity) aim to make it all or nothing,
more that the alignment is very obvious in the MV situation and can be
apparently less clear (to some) in the RM form.

I still would not say "visually align" although perhaps you could add
"and linguistically aligned," so you can tell it is more aligned with a
person's model of the situation. The UI gives hints on what aligns
with how humans think as does the data structure of a UI. Data need
not be stored in a way that works for humans, but the interface between
the rest of the software (e.g. UI) and the database API as well as the
human working with the interface to the database can be much better
than with a language that implements the RM, IMO.

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.

<snip>

b) CLR

I think the Lazza's O and others have some similar facilities - Sybase
opts for Java, but Bill is going for the whole sorry .Net kitchen sink!

Are these both SQL Server only? I don't know what the downside of CLR
is.

RISK - like you have with MV (only joking, well not really, but far
worse). Every half wit who finds regular SQL too taxing will start
building bits and pieces of smart alec code and then ram it into the
database -

That is what I figured you were thinking. Coming at it from the s/w
dev standpoint, I have mixed feelings on that one. I very
.NET-ignorant (by decision so far), however.

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!

that like all M$ stuff will fail from time to time. Argggh -
all the mayhem you can handle and then more! As a foretaste I have
already heard of ppl shelling out of sprocs to instantiate an object
that invokes a DTS package to munge the very data they are interested
in. So what if you lose a bit on the way.

laughing. Flexibility is one of those features that some folks just
hate, eh? You then have to hire good developers and have good testing
(even then I'll grant it isn't air tight).

Yep - in some places it is more dangerous and others it is desirable. Always it must be in good hands.

This simply confirms what Canute discovered. His goal may be correct
but his method not. That doesn't mean it is unachievable as the Dutch
have showed.

Unless you are talking about King Canute and the Dutch holding back the
sea? That is the only thing that comes to mind, otherwise I'm clueless
on the allusion.

Couldn't be any other conclusion could it? He didn't and they did!

I wasn't sure you wanted me to haul out the liberal arts or if there
was some techie stuff I was missing ;-)

Cheers! --dawn

Thanks for being candid about Picks top 5 shortcomings - your co-conspirators prolly think you are related to Judas Iscariot by blood :-).

Cheers, Frank.
.