MV Database old or new

[Peter McMurray]

A great deal of argument has come about on what is a MultiValue Database..

In my opinion that misses the entire point. Quite simply Dick intended it to be based on Name Value pairs and obviously Don was thinking more along the lines of what became XML

.

The argument that Pick is outdated is based on the User Interface regardless of what storage method is used.

It appears that ON Group have decided that the only way they can use a modern USER OUTPUT INTERFACE is to convert everything into SQL and use the myriad tools available.

Unfortunately this has the effect of making Pick's strengths vastly more difficult to use. 

I have seen a public service department go through numerous contractors and several months in order to get the SQL to produce pay cheques at better than one a minute. The final contractor wandered in at morning coffee time and when he left for lunch they were coming out like shelled peas.

Pick's OUTPUT interface, be it called English, Access or whatever is an excellent primary sort and simple printing procedure. As soon as one needs anything else one has to go to Basic - sadly a language that many newbies consider beneath them. Dashboards! forget it. Companies like Rocket have provided links to excellent environments for that style such as .NET but no readily available standard or even recommendation that is suitable for smaller sites.

In my opinion even that misses the point that the major issue is the USER INPUT INTERFACE. That is what every user sees every minute of every day that they use it.

Sadly JBASE is the only product that has realised that a Pick MV database in its natural form (I cannot answer for SQL Server via MVON but I doubt it) is inherently 100% UTF8 Unicode compliant over all planes. Even QM let the side down there.

UTF8 is the defacto standard for search engines and email and therefore the natural choice for storage.

It is easy to handle UTF8 input in Basic out of the box and only requires the simplest of changes to the Report Generator for Output report handling.

On these forums we have seen some sad reports where European firms have been sold MV databasesas being Unicose Compliant which, apart from JBASE, they are not. Unicode uses standard ASCII as is, but Extended Ascii is a two byte code leaving users wondering why backspace doesn't appear to work properly.

What is needed is simple screen handling that has the modern Fizz and Sparkle without being dependent on a particular search engine or the Cloud.

[Kevin Powick]

MV's greatest weakness is that data and referential integrity is typically done at the application level, whereas a RDBMS forces you to define field data types and easily allows you to maintain foreign key relationships.

These shortcomings in MV "can" be somewhat alleviated through the use of triggers, but they do not seem to be widely used, are not required by default, and can have a very large impact on performance.

So, without extensive use of triggers, nothing prevents programming errors like: Writing a "string" into an attribute that should contain a number, writing a number outside a valid range, deleting a customer record that has invoices and orders on file, etc, etc.

To ensure the data integrity of an MV system, developers are forced to have a very complete understanding of the system, which isn't a bad thing, but becomes more difficult as the system grows.

While MV developers enjoy raw power, rapid design and deployment, auditors care very much about data integrity.  Today, you cannot just "fix" a data problem with ED without auditors losing their minds.

I work extensively with both MV and Relational systems (PostgreSQL / SQL Server), and have yet to write a "repost" program for a RDBMS.  Being forced to define the data model within the database itself prevents many errors.

--

Kevin Powick

[Tony Gravagno]

I'd disagree that application-level RI is a weakness, but it's certainly fragile. In the frenzy to write and deploy code quickly, Pick developers generally don't add rigorous code to ensure RI. I'm no exception. We pride ourselves on using a model that allows us to do things without concern for proper form, and claim this is a benefit over those newfangled OOP guys who take so much longer. But while OOP has its own world of concerns, a lot of them are not the same concerns which are typical in MV systems. In summary, we have lots of rope to hang ourselves, and most Pick developers gladly use it for that purpose.

And yes, triggers are grossly under-used, but I've also found them to be grossly unstable. Most Pickies keep their code in R83-compatible mode: for lack of desire to learn new tools, for lack of trust in the tools, and for portability. The more people use the tools we have, the better the pre-release QA is for those features.

Peter wrote: "The argument that Pick is outdated is based on the User Interface"
That's true for those who don't know about the platform. For those who do know this platform and can compare it to others, Pick is outdated in that it has generally not progressed as a data model beyond R83. Indexes have been added, different file types have been added, Part files have been added (kewl feature), but we're still dealing with some of the same problems with long strings, indexing, triggers, large files, and primitive cross-file/table relations. Every platform has its own solutions, a few quite good, but no one MV platform has solved the kind of problems that cause us grief when trying to compete with the relational model.

"Dashboards! forget it. Companies like Rocket have provided links to excellent environments for that style such as .NET but no readily available standard or even recommendation that is suitable for smaller sites."

I think I might have something for you on that soon. ;)

"On these forums we have seen some sad reports where European firms...."

I'm sorry Peter, but your assertion is disproved by the wealth of non-English sites over a variety of MV platforms. You're right that multi-language support is not great, with issues with sorts, selects, etc, but these sites _are_ functional with the same likes and gripes as any English-based Pick environment.

Regards,
T

[Kevin Powick]

On Thursday, 21 September 2017 13:55:51 UTC-4, Tony Gravagno wrote:

I'd disagree that application-level RI is a weakness, but it's certainly fragile.

That "but" qualifier essentially invalidates your statement.  IOW, if it's fragile, it's weak.

 

 

In the frenzy to write and deploy code quickly, Pick developers generally don't add rigorous code to ensure RI.

Which more often than in a RDBMS results in data fixes with ED or "repost" programs.  Yes, such "fixes" often done easily and quickly, but difficult to explain to your company auditors.

 

We pride ourselves on using a model that allows us to do things without concern for proper form, and claim this is a benefit over those newfangled OOP guys who take so much longer.

Maybe you're just using OOP as an analogy, because this has nothing to do with OOP.

 

 In summary, we have lots of rope to hang ourselves, and most Pick developers gladly use it for that purpose.

The problem is that the rope gets longer the larger the project becomes.  When you have a system with hundreds of files and thousands of attributes, the ability to make changes to the system and maintain its integrity becomes difficult.  Moreover, new team members can be burdened with a vast amount of knowledge to absorb because they must ensure their applications, instead of the DB model itself, prevent "bad" data from entering the system.

 

And yes, triggers are grossly under-used, but I've also found them to be grossly unstable.

I've found the same, in D3 anyway, which doesn't bode well for offloading RI to the DB model in MV systems. 

When data and referential integrity is an integral part of the DB model, then any/all interfaces to that data (ED, UP, BASIC, mv.Net, etc.) can be "trusted" to not accidentally violate the parameters of the data model.  This is a key advantage of at RDBMS.

 

--

Kevin Powick

[Peter McMurray]

Hi Referential integrity was the very first issue that Stuart Evans and I addressed when we wrote our base system approach in 1977. 

It is very simple we define every field in a Global Application Dictionary - a file based control is a recipe for disaster. The file layouts are described using these dictionaries. We never create a data entry screen or update a file without reference to the global dictionary.

The only time we have ever experienced any issues have been when an idiot from another organisation has decided to write a quickie or do a global edit. The idea of a quickie is sheer stupidity as it takes under 5 minutes to define the outline of a program including the file definitions.

I agree with most of what you say TG however the European example is a significant issue that has been covered in this forum. The party was unaware that the umlaut and similar marks created a double character in Unicode. Please note my remark was in regard to UNICODE not EXTENDED ASCII.

MVs great strengths are simplicity of logical design, simplicity of maintenance and cross platform compatibility. Whereas SQL Server, good as it is, has none those features. Please do not even mention SQL AZURE as that exists in a perfect world where high speed internet and totally reliable electrical supply are a given. I am sure some Californians may think they have that - those of us in the real world do not.

MV is the database definition of KISS :-) Whereas SQL brings to mind the favourite saying of the long departed Bruce "If it works, fix it 'til it doesn't."

[Wols Lists]

On 21/09/17 18:55, Tony Gravagno wrote:
> In summary, we have lots of rope to hang ourselves, and most Pick
> developers gladly use it for that purpose.

You really couldn't put it better than that ... :-)

Cheers,
Wol

[Wols Lists]

On 21/09/17 19:37, Kevin Powick wrote:
> When data and referential integrity is an integral part of the DB model,
> then any/all interfaces to that data (ED, UP, BASIC, mv.Net, etc.) can
> be "trusted" to not accidentally violate the parameters of the data
> model. This is a key advantage of at RDBMS.

And if I ever get round to writing my "Open Source Pick" - *IF* - that
will be one of the first concerns ... as so it should be!

That said, referential integrity has its problems ... "every car must
have an owner. The owner has died. We can't flag the owner as dead
because he still owns a car, and a dead guy can't own a car!"

Demanding RI from the database, without realising it can be violated in
the real world, is just as much a problem as not having RI.

Cheers,
Wol

[Kevin Powick]

On Thursday, 21 September 2017 17:46:02 UTC-4, Wol wrote:

That said, referential integrity has its problems ... "every car must
have an owner. The owner has died. We can't flag the owner as dead
because he still owns a car, and a dead guy can't own a car!"

That's not an RI problem, that's a model problem.  Stating that every car must have an owner is where the design went wrong in the first place.

 

Demanding RI from the database, without realising it can be violated in
the real world, is just as much a problem as not having RI. 

I would much have the option of RI and use it to enforce a well designed model than not have it at all.

--

Kevin Powick   

[Kevin Powick]

On Thursday, 21 September 2017 17:16:22 UTC-4, Peter McMurray wrote:

 

The only time we have ever experienced any issues have been when an idiot from another organisation has decided to write a quickie or do a global edit.

Hence the reasoning for RI at the database level.  When this exists, all interfaces to the data are regulated via the model's parameters and restrictions.

 

MVs great strengths are simplicity of logical design, simplicity of maintenance and cross platform compatibility.

MV's greatest strength, which allowed it to proliferate in the early days, was that you didn't need to know very much to be dangerous. ;) 

--

Kevin Powick 

[Tony Gravagno]

On Thursday, September 21, 2017 at 11:37:44 AM UTC-7, Kevin Powick wrote:

On Thursday, 21 September 2017 13:55:51 UTC-4, Tony Gravagno wrote:

I'd disagree that application-level RI is a weakness, but it's certainly fragile.

That "but" qualifier essentially invalidates your statement.  IOW, if it's fragile, it's weak.

 

Um, yeah. You're right. :)

 

 

In the frenzy to write and deploy code quickly, Pick developers generally don't add rigorous code to ensure RI.

Which more often than in a RDBMS results in data fixes with ED or "repost" programs.  Yes, such "fixes" often done easily and quickly, but difficult to explain to your company auditors.

 

We pride ourselves on using a model that allows us to do things without concern for proper form, and claim this is a benefit over those newfangled OOP guys who take so much longer.

Maybe you're just using OOP as an analogy, because this has nothing to do with OOP.

Correct. The kind of "form" that I'm referring to includes smaller modules, strongly typed variables, references to imported libraries, variable scoping, etc. These are common in OOP languages, but not all OOP languages support every feature. The point being that better code structures do take longer to create but maintenance of OOP code is almost always easier than maintenance of monolithic and cryptic MV apps.

 

 In summary, we have lots of rope to hang ourselves, and most Pick developers gladly use it for that purpose.

The problem is that the rope gets longer the larger the project becomes.  When you have a system with hundreds of files and thousands of attributes, the ability to make changes to the system and maintain its integrity becomes difficult.  Moreover, new team members can be burdened with a vast amount of knowledge to absorb because they must ensure their applications, instead of the DB model itself, prevent "bad" data from entering the system.

I get a lot of requests to maintain existing applications - to be that guy to absorb info like that. These days I take a good amount of time to explain that a 5 minute fix could take days of research in an application where there is no documentaiton, no one to ask about how things work, no comments in code, etc. I will not Quote projects, I only Estimate, because I have no idea how long it's going to take to filter through the crud of some old developer that has built his own custom way of handling everything. Most prospects don't want to do business like that, then we hear about how sites have gone through so many developers who took so long to work on code. These days I work mostly on a fixed retainer - I get paid by the month, not by the hour. That way it doesn't matter how long it takes to find issues and make changes, as long as the job gets done in a reasonable amount of time. And the longer the relationship with the client continues the easier those kinds of changes get - because I have time to detangle some of that long rope.

 

 

And yes, triggers are grossly under-used, but I've also found them to be grossly unstable.

I've found the same, in D3 anyway, which doesn't bode well for offloading RI to the DB model in MV systems. 

When data and referential integrity is an integral part of the DB model, then any/all interfaces to that data (ED, UP, BASIC, mv.Net, etc.) can be "trusted" to not accidentally violate the parameters of the data model.  This is a key advantage of at RDBMS.

 

--

Kevin Powick

Hear Hear!

T

[Tony Gravagno]

On Thursday, September 21, 2017 at 2:16:22 PM UTC-7, Peter McMurray wrote:

I agree with most of what you say TG however the European example is a significant issue that has been covered in this forum. The party was unaware that the umlaut and similar marks created a double character in Unicode. Please note my remark was in regard to UNICODE not EXTENDED ASCII.

Again, I'm not disagreeing with the issues that you've cited. But for the record there are many apps that use Unicode over MV, like Arabic over mvBase 1.x, Chinese over Universe and D3, and Japanese, Russian, Italian, French, and Thai over D3. Note your specific quote: "European firms have been sold MV databasesas being Unicose Compliant which, apart from JBASE, they are not." I'm saying that while there are faults in various releases of various platforms, it is not correct to lump all of them except jBase into a single category of not being Unicode Compliant. Functional, live applications prove your summary to be simply an over-statement.

 

MVs great strengths are simplicity of logical design, simplicity of maintenance and cross platform compatibility. Whereas SQL Server, good as it is, has none those features.

Well, yeah it does, and I believe most SQL Server DBAs will attest to that. I've spent the last couple years getting more involved with SQL Server and in my experience there is as little maintenance as any MV system I use daily. As to cross-platform, SQL Server now runs over Linux. As I say, the longer we go believing we have some edge over RDBMS, the longer we give them to develop past their own limitations to invalidate self-gratifying claims of superiority.

Again, I'm not saying you're entirely wrong, I'm just saying I think some of these claims are outdated and a bit self-gratifying. We need to ensure our claims amongst ourselves are accurate, or those who know better will ensure we never get called back for second presentations.

 

Please do not even mention SQL AZURE as that exists in a perfect world where high speed internet and totally reliable electrical supply are a given. I am sure some Californians may think they have that - those of us in the real world do not.

You do realize that you're talking about cloud services that have no connection to your local electrical supply?

And that the network connection is between the hosted application server and the database, not your local office?

Perhaps you have this confused with some other technology.

 

MV is the database definition of KISS :-) Whereas SQL brings to mind the favourite saying of the long departed Bruce "If it works, fix it 'til it doesn't."

The database is simple. What developers do to it is what helps to define "spaghetti code". I have no problem navigating database management systems and no problem navigating relational DBMS. Some of my very unproductive days are spent chasing down write-only BASIC code and SQL stored procs. The fault isn't in the models, its in the people who use them. That concept is universal, from tools like pencils to cars and cell phones to airplanes.

T