SQL Server is Now a MultiValue DBMS

[Dawn Wolthuis]

This is both a clarification regarding SQL Server now really being an MV DBMS and also some questions before I head into a meeting with Microsoft next week.

SQL Server is a MultiValue DBMS AND it is the top of the line DBMS for pretty much all other reasons. Therefore, from what I have seen in the industry, for most business applications SQL Server is the best MV DBMS there is. I recognize we need to prove that to some folks, and I'm not certain how best to do that.

Question 1:

If you were to see that MultiValue data stored in SQL Server with the same data available to both SQL (read/write views) and to MV (MV BASIC, PROCS, even ED), what more would you need to know to be 100% certain that SQL Server is an MV DBMS?

For example, 

From the MV perspective: column 1 = @ID, column 2 = @RECORD

From the SQL perspective, single-valued fields become columns, MVs are logically split as new tables from base tables with read/write views of everything

Sure we also have tools to normalize the snot out of the data on the SQL Server side and still do MV reads and writes, but, better yet, you can retain the flexibility of the MV data model by using SQL Server as an MV DBMS, value marks and all, with all of your SQL tools seeing the data as SQL. Both projections of the same data work. That is why the projects to move MV applications to SQL Server are now so successful. SQL Server has a ton of features that support MV data models today.

I probably don't have to show the Gartner Group reports for most IT folks to know that SQL Server is arguably the best DBMS on the market today, certainly among the very best out there for any companies writing new business software applications. The reliability and ongoing admin is extremely impressive, including tools like Always On. Whether looking for 24-8 uptime, scalability, BI/reporting, cloud, or usability, SQL Server ranks at the very top of the DBMS offerings.

One thing it previously lacked was the ability to work well with MultiValue applications. I have heard plenty of horror stories from the days of trying to move from an MV to a relational DBMS. We have been using SQL Server AS an MV DBMS, and it shines. There are Case Studies that prove that MV applications can now run on SQL Server without all of the pain of old migration from MV to relational models. This is a recent one, from the very first site to also use .NET as their run machine with MV BASIC as managed code, so their entire platform is Microsoft. This is even from a formerly SB+ site

http://ongroup.com/web/pdf/case-studies/ABSA-MVONsharp.pdf

Question 2: What would you like to hear or need to hear directly from Microsoft, rather than from me or a site running on SQL Server, so that you know that 

SQL Server is the best MultiValue DBMS on the market today, providing a huge boost in value to the VARs/ISVs and end-customers who trade in their hash table MV for an industry Best in DBMS software?

Thanks in advance for your help on this (and for protecting me from at least two people who are likely to jump all over me for asking such questions in this forum).  Smiles.  --Dawn

Dawn M. Wolthuis

President, Tincat Group, Inc.

EVP, ONgroup Intl

Take and give some delight today

[Glenn Sallis]

Hi Dawn,

Thanks for your interesting posting regarding SQL Server.

Can you confirm as of which version of SQL Server your statements are valid?

Whilst some may be upset by your posting, we have to remember that this is ultimately about business and we have to keep an open mind and avoid emotional attachment to a specific technology or "favourite" DBMS flavour.

From my point of view as a consultant, the best technology is the one which helps my client to be most succesful and efficient in their daily business.

Glenn Sallis

Glenn Sallis IT Consulting, Germany

[Kevin King]

I agree wholeheartedly with Glenn when he says "the best technology is the one which helps my client to be the most successful and efficient in their daily business".  Simply could not agree more.  

Dawn, while I find your company's tech to be interesting and novel, I fear your claims of SQL server being "best" is clouded by your present reality, especially in the light of Glenn's assertion.  The problem here is that "best" has to be established in a specific context.  To say "best" of anything without any context is at best disingenuos, and at worst it's a bald faced lie told to establish a context of truth simply by having been stated (i.e. "slimy marketing").  So much confidence is eroded with empty assertions of "best".

For me, I couldn't give a rats ass about what Microsoft has to say on the matter.  The cost of SQL Server and the unbelievable pain and suffering of dealing with Microsoft tech support is enough for me to say "not for me, please".  I would never say "never" in terms of Microsoft - simply because that shows a bigotry in the opposite direction - but up to this point I have yet to be involved in a project where SQL Server is the "best" option.

I wrote an article on this very topic back in 2001.  I guess this is one of those topics that is never going to end...

https://www.precisonline.com/2017/09/are-you-a-technology-bigot/

Dawn, I still count you as a valued friend, but unless you back up "best" with some context, do not be surprised by some flames.

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

--

-K

[Rick Weiser]

Hi Kevin,

I mostly agree with you.  Glenn's points are right on.  The best DBMS is what works best for the client that I am working for at the time.  I have rolled into clients where the top brass needs data in SQL Server but not all the data.  I have also run into clients that are pure Pick shops and introducing SQL server would mean investing in much more infrastructure (hardware, software and personnel). There are other ways to open the data without storing it in SQL server.

"Best" is always relative in this market.

Just my 2 cents.

Rick

[Dawn Wolthuis]

While I definitely agree that a best-of-breed product is not necessarily the best business decision for any particular site there are some qualifying and quantifiable measures that allow for discussions of good, better, best.

I recently told someone that having written applications with CICS COBOL and VSAM files in the 80's, I can imagine a scenario where VSAM files are still a good choice for an organization. That doesn't mean that such indexed-sequential file systems make the list of the contenders as best database system today.

While I can see all of the places where Gardner Group puts SQL Server at the top, both for OLTP and BI, there are specific cases where Oracle or UniVerse might beat SQL Server with one feature or benchmark or another. There are other cases where I would look at the situation and not switch to a better DBMS, perhaps for short-term cost reasons. SQL Server does have a production-deplorable free version that many switching from Access are using, but for most installations, more memory would be helpful. What we have found is that many MV sites already pay for SQL Server, so they can use what they have.

Here's a fact to pull in -- we went to DBTA (Database Trends and Applications) with their survey where they have people vote for the best MultiValue DBMS. This year they could not add SQL Server to the list of options as they said it did not qualify. We have not yet learned what it will for DBTA to accept it as an option. So, that is where my statement comes in. I need to dot some i's to pass muster with DBTA. I'm asking folks in the MV space what they need from us to verify that SQL Server is now an MV DBMS. I think it gives us "roots and wings" to have our applications and top notch replication too, for example.

So, would you at least agree that SQL Server should make a survey about MV as one of the options for best MultiValue DBMS?   

We can also speak to Windows reliability. Also, for those who love Linux, soon SQL Server will be generally available there. We have learned that for some companies there seems to be a turning point with Windows servers swapping places with Linus servers for those who are weary of the greater version skew issues of Linux and open source libraries. 

Either way -- we can let the site choose the O/S as soon as we find one interested in SQL Server on Linux. We are happy with the reliability and even the scalability on Windows to date, as are those running MV applications with SQL Server as their DBMS, but I'm guessing some linux shop will prefer that at some point, and the vast DBMS technical resources dedicated to SQL Server are busy making it sing. By the way, no other MV DBMS company comes anywhere close to the number of engineers working on platforms, features, reliability, etc that Microsoft has working on SQL Server.

Thanks.  --Dawn

Sent from my iPad

To unsubscribe, email to: mvdbms+un...@googlegroups.com

[Dawn Wolthuis]

I know it has been run on everything since 2008 R2, perhaps even earlier, but we no longer do QA on that platform IIRC. I'll verify and get back to you on that, Glenn.

--Dawn

Sent from my iPad

--

[Peter McMurray]

Interesting! My initial assessment of OnGroup design as being a program to transfer Pick to SQL Server is spot on.

 

The market for this is the large global organisation whereas its value to thousands of Pick users is zero.

SQL Server is just under $AU5000 PER CORE and it does require power plus an onsite IT presence or a full blown Cloud installation.

Pick on the other hand is the definition of Keep It Simple S******

Thousands of businesses actually have small user bases. 

A typical Oil distribution franchise can turn $AU50 million per annum with 3 or 4 operators. A modern PC running Microsoft 10 runs like lightning on a peer to peer server basis. 

A large Franchise business may have hundreds of depots each requiring only one small Pick server each. I know of one developer who sold 20,000 seats to hundreds of car dealerships.

The Cloud is a myth in this situation, much as I would like it to be fantastic, imagine if it was Florida based right now.

Pick has been run since inception on the small shop doing ace work with large shops like Insurance companies being the exception.

It boils down to MARKET MARKET MARKET. I wish OnGroup well but they are not aimed at the small shop - there again the small shop is probably dead and well sold rubbish like MYOB is king.

[Jay LaBonte]

Dawn,

 

I think there is a big different between “being” an MV DBMS such as U2 or other Multivalued database’s vs an SQL database that can hold MultiValue data as a varchar. If simply holding data that contains data delimited using MultiValues, sub values and attributed marks classifies the database as MultiValue, then you can claim any database is MultiValue.

 

I don’t see Microsofts SQL server as being a “legitimate” multivalued database. I would actually assert the reverse that databases such as Universe are the “best” multivalued database that supports SQL. After all SQL is a query language, and not a database until itself.

 

Just my two cent.

 

Regards,

 

Jay LaBonte President & CEO   (: 561-705-3688 |*: jlab...@paradigm-systems.us 2234 North Federal Hwy, Suite 1056, Boca Raton, FL 33481 www.paradigm-systems.us

 

To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

 

--

-K

 

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Albert Kallal]

 

I would like more info on how mapping of such data is seen and used by SQL server. (Cleary the mv side and data basic is fine and dandy).

 

A simple white paper that explains how such logical MV data (as opposed to physical) data is to be consumed by industry standard SQL tools would be a gazillion times better than some “claim” or hype about SQL server being a multi-value database.

 

All I see here is some attempt looking to hang our credibility off of Microsoft or IBM.

 

Your post reads somewhat like a child desperate looking for credibility from Microsoft - that's not really going to make or break MV systems in this regards.

 

I mean, as a “general” rule, MV databases such as D3 had the addition of ODBC, then you had to provide SQL table mapping commands to map out MV data as a separate table. And it made perfect sense to me when I exposed MV tables to ODBC.

 

However NOW we talking about the REVERSE here. The data is in SQL server, but stored as mv format data.

 

So I would like to see how is the above mapping handled and thus how is the data presented as SQL tables for consumption by standard ODBC clients to SQL server.

 

Until such time above details are available, then the claim of SQL server being a great mutli-value database is sort of hollow and a weak case. (and I suspect that some papers exist from the vendor - I just not seen them).

I am a long time MV user, but these days my area is SQL server, .net etc. I respect and love MV's systems, but I am hard pressed to make the case that SQL server is a "general" solution for MV databases. And the vast majority of my clients use the free edition of SQL server (with 10 gig file sizes - I hard pressed to find a customer needing more then the free edition of SQL server).

 

Regards,

Albert D. Kallal

Edmonton, Alberta Canada

Pleasenos...@msn.com

[Dawn Wolthuis]

Excellent, Jay -- this is the conversation I want to have. I think by any criteria that makes Cache' from InterSystems a MultiValue DBMS, SQL Server also is. Cache' stores data as a b-tree, not hash tables.

Are you thinking that only hash table MV DBMS products can be classified as an MV DBMS?

--Dawn 

Dawn M. Wolthuis

Take and give some delight today

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

 

--

-K

 

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[Dawn Wolthuis]

Thanks Albert, this is helpful. When we show people the answers to the questions you have, they see that SQL Server is working as both an MV DBMS and a SQL DBMS, but the case study I pointed to is not a detailed technical briefing on that.

We can run MV BASIC and Query against MV data that is normalized into typed columns, but our standard approach out of the box is to use SQL Server like those who use it as a key-value store. More companies than one might guess use an RDBMS this way (Salesforce does with Oracle, for example).

Primary key is @ID

Column = the value of the record = @RECORD

Our tools virtually normalize the data (or actually do, but I consider that a lesser implementation because I'm not a relational fan -- some might prefer that approach) into updatable Views. The input to those processes are PHrases in the DICTS that can be tailored by the site as input to the utilities. 

Additionally, we have built enough aspects of MV right into SQL Server to optimize performance.

These "management bullets" are higher level than what you are looking for, however, so your suggestion of writing this as a technical paper or a white paper is a good one.  

Thanks.  --Dawn

Dawn M. Wolthuis

Take and give some delight today

--

[Jay LaBonte]

I think first we must determine what classifies a MV database as a MultiValue. Once the accepted definition is established, then and only then can you make such a claim that SQL Server is a MV DBMS.

 

I personally do not consider a database that stores its data as a giant VARCHAR as a valid MV database. Yes, SQL Server can store MV data, but it cannot natively interpret that data without someone writing translations to parse the giant VARCHAR.  If simply holding data delimited with ASCII characters 252,253 and 254 classified the storage medium as MV then notepad.exe or Word as a MultiValue database and we all know they is not MV databases.

 

 

So the question is what differentiates a Multivalue Database from a database storing data in a MultiValue style. (I can slap a Ferrari emblem on a Toyota, but that does not make the Toyota a Ferrari.)

 

 

Regards,

 

Jay LaBonte President & CEO   (: 561-705-3688 |*: jlab...@paradigm-systems.us 2234 North Federal Hwy, Suite 1056, Boca Raton, FL 33481 www.paradigm-systems.us

 

 

From: dawnwo...@gmail.com [mailto:dawnwo...@gmail.com] On Behalf Of Dawn Wolthuis
Sent: Sunday, September 17, 2017 7:02 PM
To: mvd...@googlegroups.com
Subject: Re: [mvdbms] Re: SQL Server is Now a MultiValue DBMS

 

Excellent, Jay -- this is the conversation I want to have. I think by any criteria that makes Cache' from InterSystems a MultiValue DBMS, SQL Server also is. Cache' stores data as a b-tree, not hash tables.

To unsubscribe, email to: mvdbms+un...@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

 

--

-K

 

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com

[Jay LaBonte]

Dawn,

 

I think first we must determine what classifies a MV database as a MultiValue. Once the accepted definition is established, then and only then can you make such a claim that SQL Server is a MV DBMS.

 

I personally do not consider a database that stores its data as a giant VARCHAR as a valid MV database. Yes, SQL Server can store MV data, but it cannot natively interpret that data without someone writing translations to parse the giant VARCHAR.  If simply holding data delimited with ASCII characters 252,253 and 254 classified the storage medium as MV then notepad.exe or Word as a MultiValue database and we all know they is not MV databases.

 

 

So the question is what differentiates a Multivalue Database from a database storing data in a MultiValue style. (I can slap a Ferrari emblem on a Toyota, but that does not make the Toyota a Ferrari.)

 

 

Regards,

 

Jay LaBonte President & CEO   (: 561-705-3688 |*: jlab...@paradigm-systems.us 2234 North Federal Hwy, Suite 1056, Boca Raton, FL 33481 www.paradigm-systems.us

 

 

From: dawnwo...@gmail.com [mailto:dawnwo...@gmail.com] On Behalf Of Dawn Wolthuis
Sent: Sunday, September 17, 2017 7:02 PM
To: mvd...@googlegroups.com
Subject: Re: [mvdbms] Re: SQL Server is Now a MultiValue DBMS

 

Excellent, Jay -- this is the conversation I want to have. I think by any criteria that makes Cache' from InterSystems a MultiValue DBMS, SQL Server also is. Cache' stores data as a b-tree, not hash tables.

To unsubscribe, email to: mvdbms+un...@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

 

--

-K

 

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com

[Jay LaBonte]

Dawn,

 

I think first we must determine what classifies a MV database as a MultiValue. Once the accepted definition is established, then and only then can you make such a claim that SQL Server is a MV DBMS.

 

I personally do not consider a database that stores its data as a giant VARCHAR as a valid MV database. Yes, SQL Server can store MV data, but it cannot natively interpret that data without someone writing translations to parse the giant VARCHAR.  If simply holding data delimited with ASCII characters 252,253 and 254 classified the storage medium as MV then notepad.exe or Word as a MultiValue database and we all know they is not MV databases.

 

 

So the question is what differentiates a Multivalue Database from a database storing data in a MultiValue style. (I can slap a Ferrari emblem on a Toyota, but that does not make the Toyota a Ferrari.)

 

 

Regards,

 

Jay LaBonte President & CEO   (: 561-705-3688 |*: jlab...@paradigm-systems.us 2234 North Federal Hwy, Suite 1056, Boca Raton, FL 33481 www.paradigm-systems.us

 

 

From: mvd...@googlegroups.com [mailto:mvd...@googlegroups.com] On Behalf Of Dawn Wolthuis
Sent: Sunday, September 17, 2017 4:24 PM
To: mvd...@googlegroups.com
Subject: Re: [mvdbms] Re: SQL Server is Now a MultiValue DBMS

 

I know it has been run on everything since 2008 R2, perhaps even earlier, but we no longer do QA on that platform IIRC. I'll verify and get back to you on that, Glenn.

[Jay LaBonte]

[Jay LaBonte]

Dawn,

 

I think first we must determine what classifies a MV database as a MultiValue. Once the accepted definition is established, then and only then can you make such a claim that SQL Server is a MV DBMS.

 

I personally do not consider a database that stores its data as a giant VARCHAR as a valid MV database. Yes, SQL Server can store MV data, but it cannot natively interpret that data without someone writing translations to parse the giant VARCHAR.  If simply holding data delimited with ASCII characters 252,253 and 254 classified the storage medium as MV then notepad.exe or Word as a MultiValue database and we all know they is not MV databases.

 

 

So the question is what differentiates a Multivalue Database from a database storing data in a MultiValue style. (I can slap a Ferrari emblem on a Toyota, but that does not make the Toyota a Ferrari.)

 

 

Regards,

 

Jay LaBonte President & CEO   (: 561-705-3688 |*: jlab...@paradigm-systems.us 2234 North Federal Hwy, Suite 1056, Boca Raton, FL 33481 www.paradigm-systems.us

[Dawn Wolthuis]

Your point, Jay, that SQL is a language is a good one. With the MultiValue Family Tree, http://www.zumasys.com/pdf/the-multivalue-family-tree.pdf , I trace the heritage of the MV Query language. So, I define an MV DBMS much as you are defining a SQL DBMS. So, do you then see how it makes sense to call SQL Server that includes tools for MV, including the MV query language, as both an SQL and an MV DBMS? Both query languages work against the exact same data.

We now have several options of DBMS tools that provide a projection for both of these languages. SQL Server has the best SQL implementation of all of them, especially if you consider that every tool out there for reporting/BI and other purposes works with SQL Server. The 3rd parties have to make it work rather than us having to make the 3rd party software work with U2, for example.

I do think Cache' has an incredibly fast SQL implementation (and they translate all MV query into Cache' SQL before executing it). We will have more performance data from existing live sites in the future, but SQL Server is also a very fast DBMS for MV the way we are using it.

--Dawn

Dawn M. Wolthuis

Take and give some delight today

On Sun, Sep 17, 2017 at 5:53 PM, Jay LaBonte <jlab...@paradigm-systems.us> wrote:

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

 

--

-K

 

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[Dawn Wolthuis]

Jay -- you and I agree on your statement here -- "I think first we must determine what classifies a MV database as a MultiValue. Once the accepted definition is established, then and only then can you make such a claim that SQL Server is a MV DBMS."

Do you agree with the message I just sent where I suggested that a SQL DBMS is one where the SQL language can be used data stored in it and an MV DBMS is one where the MV language can be used with data stored in it?  Therefore, UniData is both an MV and SQL DBMS when you use SQL / ODBC tools. SQL Server is both an MV and a SQL DBMS when you use MV libraries/tools.

So, both U2 and SQL Server are both MV and SQL DBMS products. SQL Server is superior by most objective criteria, but I'll agree with everyone who says that does not mean that for any particular instance it will make sense to move to SQL Server. Some will not want to pay for SQL Server, for example, even if it optionally gets them out of the "per seat" world.

(by the way, are you getting these huge postmaster responses about an error from this list -- can the moderators remove the offending email address?)

Dawn M. Wolthuis

Take and give some delight today

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

 

--

-K

 

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[stope19]

To a pretty large degree this appears to be 'playing word games'. One could perhaps equally argue that a MV DBMS is one that natively supports the MV data model through storage and retrieval mechanisms. An SQL DBMS is one that natively supports SQL ..etc. This would make MV implemented on top of SQL Server more of an 'emulation' of a MV database. I get that you have a product to flog, but (IMHO) this manipulation of words to get the definition you want – does not achieve much… If you really want to call SQL Server a MV DBMS, go right ahead - but don't expect to take everyone with you.. YMMV

On Monday, 18 September 2017 09:43:58 UTC+10, Dawn Wolthuis wrote:

Jay -- you and I agree on your statement here -- "I think first we must determine what classifies a MV database as a MultiValue. Once the accepted definition is established, then and only then can you make such a claim that SQL Server is a MV DBMS."

Do you agree with the message I just sent where I suggested that a SQL DBMS is one where the SQL language can be used data stored in it and an MV DBMS is one where the MV language can be used with data stored in it?  Therefore, UniData is both an MV and SQL DBMS when you use SQL / ODBC tools. SQL Server is both an MV and a SQL DBMS when you use MV libraries/tools.

<snip>

[Jay LaBonte]

Stope19,

I agree with you that these are word games and that they have an MV emulator, and not an MV dbms. Like I said, you can label it anything you want, but just because you call it MV, does not make it so.

Sent from my iPad

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com

[Dick Thiot]

I would like to jump in here.  Jay and stope19, how do you define a native MV database as opposed to a emulator?  From your comments I come to the conclusion that the database must support traditional hashed files.  However many of the MV databases today including Universe and Unidata support other storage algorithms rather than the traditional Pick hashed key table.  

The many of us that have been around the MultiValue database market for a long period of time know that the MV hashed key method including variable length records is a very efficient way to store and retrieve the data.  For small businesses, it is a very cost effective way to implement a MV system that manages the information required by their business.  There are also many companies who are not small businesses or who have more than one application in their business.  I believe that this is the market that OnGroup's products target.

At one time I probably would have classified this type of product as an emulator but there was a time where I classified Prime and Universe as emulators because they did not have modes and a Pick assembler.  However, now those products are considered mainstream MV products.  In the same way I have come to the determination that OnGroup is similar.

Just my two cents.

Dick

Disclaimer: I am not directly affiliated with OnGroup nor do I sell their products.  I have evaluated their products and have been impressed with what I have seen and tested.

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[Dick Thiot]

Dawn,

I also received the rejected message which was caused by the email address u...@dmsnavigator.co.uk.

Dick

[Mark Taylor]

> I would like to jump in here.

So would I. To me a multi-valued database is any database that allows you
to store multiple levels of values that are *directly* addressable once a
record is selected.

A text file can be a database, but not a multi-valued database since you
must parse the contents of a record into values once it is retrieved.

MSSQL, MySQL, ProgreSQL, and others are a multi-valued database since you
*can* address a level of values, by name or number, once a record is
selected. Albeit only values in the second level.

Multi-valued databases with more levels are what we in the MV world have
traditionally called multi-valued databases. Records are selected, then
values and sub-values can be addressed either by name or number without
having to write code to parse additional values beyone the record.

It is the ability to address values without having to parse a record that
makes the database multi-valued to me.


Mark

[Ed Clark]

It’s sort of playing word games, but in this context words matter because Dawn wants to know what is required for DBTA (Database Trends and Applications) to apply the label “MV DBMS” to SQL Server.

Traditionally, I think the requirement would have been to buy a full page ad on the back of the next print issue :)

Ridiculously, you could point to a hard drive on a shelf and say that it is an MV DBMS, because “with the right tools” you could port an mv application to it. (Similarly ridiculous, TCP/IP has been implemented by both carrier pigeon and flag semaphore).

You could say that dBase is an MV DBMS or a SQL database, because “with the right tools”…. 

I read the word “emulation” in some of the responses. But essentially *EVERY* application is an emulation at some level. Bits are made to emulate letters, numbers, and words, and then structures like records..

And a single database product can function in more than one category. Both SQL and MV, as Dawn point out for UniData—though some people might argue that UniData is not a SQL database, but just emulates sql. It doesn’t get included in many lists of SQL databases. And someone mentioned that Prime Information wasn’t accepted as a “Pick” database by some people. But things need to be categorized…..

Maybe databases are mostly categorized by their underlying storage structure (which for every database is just bits, but lets not go into that again). So, rows and columns are “relational”, and frames and groups are “Pick”. That doesn’t work well though, because then there aren’t actually any SQL databases—they are just “relational” and SQL is just an “emulation”—a tool.

So what makes a database “MV”?

I’d say that it has to:

  1: Provide logical storage as items in files with item ids, attributes, values, and sub values.

  2: Provide a large subset of the features that are considered part of multivalve (basic, proc, TCL with familiar verbs, query with dictionaries, spooler, debugger, runoff, ED, assembler, user exits, menus). Not all—just most.

  3: Be able to support the migrations of existing multivalued applications without excessive re-coding.

  4: Have all the above features out of the box, and entirely supported by the database vendor without any additional 3rd party tools.

If you have that, then you’re a multivalued database.

On Sep 17, 2017, at 7:43 PM, Dawn Wolthuis <dw...@tincat-group.com> wrote:

Jay -- you and I agree on your statement here -- "I think first we must determine what classifies a MV database as a MultiValue. Once the accepted definition is established, then and only then can you make such a claim that SQL Server is a MV DBMS."

Do you agree with the message I just sent where I suggested that a SQL DBMS is one where the SQL language can be used data stored in it and an MV DBMS is one where the MV language can be used with data stored in it?  Therefore, UniData is both an MV and SQL DBMS when you use SQL / ODBC tools. SQL Server is both an MV and a SQL DBMS when you use MV libraries/tools.

So, both U2 and SQL Server are both MV and SQL DBMS products. SQL Server is superior by most objective criteria, but I'll agree with everyone who says that does not mean that for any particular instance it will make sense to move to SQL Server. Some will not want to pay for SQL Server, for example, even if it optionally gets them out of the "per seat" world.

(by the way, are you getting these huge postmaster responses about an error from this list -- can the moderators remove the offending email address?)

Dawn M. Wolthuis

Take and give some delight today

On Sun, Sep 17, 2017 at 6:20 PM, Jay LaBonte <jlab...@paradigm-systems.us> wrote:

I think first we must determine what classifies a MV database as a MultiValue. Once the accepted definition is established, then and only then can you make such a claim that SQL Server is a MV DBMS.

 

I personally do not consider a database that stores its data as a giant VARCHAR as a valid MV database. Yes, SQL Server can store MV data, but it cannot natively interpret that data without someone writing translations to parse the giant VARCHAR.  If simply holding data delimited with ASCII characters 252,253 and 254 classified the storage medium as MV then notepad.exe or Word as a MultiValue database and we all know they is not MV databases.

 

 

So the question is what differentiates a Multivalue Database from a database storing data in a MultiValue style. (I can slap a Ferrari emblem on a Toyota, but that does not make the Toyota a Ferrari.)

 

 

Regards,

 

Jay LaBonte President & CEO   (: 561-705-3688 |*: jlab...@paradigm-systems.us 2234 North Federal Hwy, Suite 1056, Boca Raton, FL 33481 www.paradigm-systems.us

<image001.jpg>
<image008.jpg><image009.jpg><image010.png>	<image011.png> <image012.png> <image013.png>

 

 

From: dawnwo...@gmail.com [mailto:dawnwo...@gmail.com] On Behalf Of Dawn Wolthuis
Sent: Sunday, September 17, 2017 7:02 PM

To: mvd...@googlegroups.com
Subject: Re: [mvdbms] Re: SQL Server is Now a MultiValue DBMS

 

Excellent, Jay -- this is the conversation I want to have. I think by any criteria that makes Cache' from InterSystems a MultiValue DBMS, SQL Server also is. Cache' stores data as a b-tree, not hash tables.

 

Are you thinking that only hash table MV DBMS products can be classified as an MV DBMS?

 

--Dawn 

Dawn M. Wolthuis

Take and give some delight today

 

On Sun, Sep 17, 2017 at 5:53 PM, Jay LaBonte <jlab...@paradigm-systems.us> wrote:

Dawn,

 

I think there is a big different between “being” an MV DBMS such as U2 or other Multivalued database’s vs an SQL database that can hold MultiValue data as a varchar. If simply holding data that contains data delimited using MultiValues, sub values and attributed marks classifies the database as MultiValue, then you can claim any database is MultiValue.

 

I don’t see Microsofts SQL server as being a “legitimate” multivalued database. I would actually assert the reverse that databases such as Universe are the “best” multivalued database that supports SQL. After all SQL is a query language, and not a database until itself.

 

Just my two cent.

 

Regards,

 

Jay LaBonte President & CEO   (: 561-705-3688 |*: jlab...@paradigm-systems.us 2234 North Federal Hwy, Suite 1056, Boca Raton, FL 33481 www.paradigm-systems.us

<image001.jpg>
<image014.jpg><image015.jpg><image016.png>	<image017.png><image018.png> <image019.png>

 

To unsubscribe, email to: mvdbms+un...@googlegroups.com

[Wols Lists]

On 18/09/17 00:43, Dawn Wolthuis wrote:
> Jay -- you and I agree on your statement here -- "I think first we must
> determine what classifies a MV database as a MultiValue. Once the
> accepted definition is established, then and only then can you make such
> a claim that SQL Server is a MV DBMS."

First I think we need to define what we mean by the term "database" - MV
people and relational people can't even agree on what the word means!

>
> Do you agree with the message I just sent where I suggested that a SQL
> DBMS is one where the SQL language can be used data stored in it and an
> MV DBMS is one where the MV language can be used with data stored in
> it? Therefore, UniData is both an MV and SQL DBMS when you use SQL /
> ODBC tools. SQL Server is both an MV and a SQL DBMS when you use MV
> libraries/tools.
>

No. A MultiValue platform is one that supports a MultiValue aware
language, and a SQL platform is one that supports the SQL language
definition. Note I carefully used the word "platform" here, not database :-)

And actually, I have to disagree most strongly here with Jay - in order
for a database *engine* to be classified as MV, it *must* store its data
as a giant VARCHAR. A MultiValue engine manipulates multiple key/value
stores - whether they are organised as a b-tree or a hash or in a
directory is irrelevant. Okay, if they required a linear search to find
a key I'd say that they are too primitive to be MV, but they're still
usable as a MV datastore ... By these standards, SQL Server is a
perfectly functional MV *engine* - declare a table with a primary key
and a varchar value, and there we have it ... but it's not a proper
engine because it doesn't enforce primary keys.

This definition clearly says that BerkeleyDB/SleepyCat DB are perfectly
acceptable MV engines, because I believe that is exactly what they are -
hashed key/value stores.

> So, both U2 and SQL Server are both MV and SQL DBMS products. SQL Server
> is superior by most objective criteria, but I'll agree with everyone who
> says that does not mean that for any particular instance it will make
> sense to move to SQL Server. Some will not want to pay for SQL Server,
> for example, even if it optionally gets them out of the "per seat" world.
>

NO! Most definitely NO! U2 is both MV and SQL, because it has an MV
platform layer atop the engine, and a SQL platform layer atop the
engine. SQL Server is *not* an MV DBMS product because it does not have
an MV platform layer (on the other hand, MVON Express *is* an MVDBMS
product because it has an MV layer on top of the key/value datastore
that is SQL Server :-)

Imho one thing that you have missed that is *crucial* to MultiValue is
that it is *self* *referential*. Talking in PI terms, once you've
grokked DICT.DICT you know all you need to know about the file
structure. Once you've grokked VOC, you know all you need to know about
the account structure. And once you've grokked both of them, you know
all you need to know about MV :-)

Pick has no concept of data and metadata. But it's easy to keep them
apart. Let's look at DICT.DICT ...

F
DICT.DICT
DICT.DICT

It's a self-describing file - it's both data and metadata at the same
time. Then we get

F
D_VOC
DICT.DICT

It's now describing the data in the VOC metadata (D_VOC) file

And finally

F
VOC
D_VOC

We have the metadata D_VOC file describing the data in the VOC file. The
point is, we can treat any key/value store as either data or metadata,
and use the exact same tools to access it.

Can you explain to me how to do that in something like SQL Server with
its hidden tables, and special tools for accessing table definitions,
and all that stuff? The SQL language platform is *very* un-MV-like.

And lastly (well, I'll probably think of another last word later on :-),
in MV the concept of a list is a first class concept. It doesn't even
exist in the relational world. Can SQL Server manipulate lists as first
class citizens? I don't know.

So, if you want to implement an MV platform on top of SQL Server, I
would say that the result is a perfectly acceptable MV database. But SQL
Server itself is not - an MVDBMS encompasses a lot more than an RDBMS
such as SQL Server.

Cheers,
Wol

>
> Dawn M. Wolthuis
>
> Take and give some delight today
>
> On Sun, Sep 17, 2017 at 6:20 PM, Jay LaBonte
> <jlab...@paradigm-systems.us <mailto:jlab...@paradigm-systems.us>> wrote:
>
> I think first we must determine what classifies a MV database as a
> MultiValue. Once the accepted definition is established, then and

> only then can you make such a claim that SQL Server is a MV DBMS. ____
>
> __ __

>
> I personally do not consider a database that stores its data as a
> giant VARCHAR as a valid MV database. Yes, SQL Server can store MV
> data, but it cannot natively interpret that data without someone
> writing translations to parse the giant VARCHAR. If simply holding
> data delimited with ASCII characters 252,253 and 254 classified the
> storage medium as MV then notepad.exe or Word as a MultiValue

> database and we all know they is not MV databases.____
>
> __ __
>
> __ __

>
> So the question is what differentiates a Multivalue Database from a
> database storing data in a MultiValue style. (I can slap a Ferrari

> emblem on a Toyota, but that does not make the Toyota a Ferrari.)____
>

[Glen Batchelor]

I have been developing with Progress for over a year now and have to say that I do not see a technical drawback, storage or query related, moving from MV. In fact I believe that the qualities I used to tout for MV simply lead our development in one direction and the language was restrictive. The query language in Progress is built into the development language, 100 times more powerful criteria and output-wise and even users can be shown how to write simple screen reports. SQL Server is now MV? Meh. I actually prefer dealing with data in Progress now than MV or SQL server and I still work with all 3.

[Jay LaBonte]

Wol,

I couldn’t agree more. You are correct for calling me out on my reference to VARCHAR's, My intent was that SQL would need an add-on from a third party in order to parse the VARCHAR, where as in a MV environment, the various elements of a data record can be directly addressed.

I also agree with Ed's four points as to what makes a database MV.

Regards,
Jay LaBonte
President & CEO

If you are using UniVerse or UniData, you should consider looking at Mercury Database Console.

[Jay LaBonte]

I just took a quick look at the International Spectrum site for the definition of MultiValue, since they actually own the rights to the MultiValue term and Logo, even though they have made it available for anyone involve in MultiValue.

 

Here is their definition:

 

“MultiValue databases differ from traditional relational database in that they have features that support and encourage the use of attributes having a list of values, rather than all attributes having a single value.”

 

Based on this definition I think Ed’s list comes the closest: (comments in parentheses are mine.)

 

  1: Provide logical storage as items in files with item ids, attributes, values, and sub values. (attributes having a list of values)

  2: Provide a large subset of the features that are considered part of multivalve (basic, proc, TCL with familiar verbs, query with dictionaries, spooler, debugger, runoff, ED, assembler, user exits, menus). Not all—just most. (features that support and engourage the use of attributes)

  3: Be able to support the migrations of existing multivalued applications without excessive re-coding. (Not directly in the definition about but a valid point – compatability.)

  4: Have all the above features out of the box, and entirely supported by the database vendor without any additional 3rd party tools. (If you have to bolt on third party software, then it is an emulation.)

 

 

Regards,

Jay LaBonte

 

[Patrick Payne]

While different systems can "emulate" each other (MV can emulate SQL with out ODBC layers and systems like Onware and jBase can store MVdata in SQL systems as blobs) the actual storage concepts are important.  While MV can emulate SQL it may not have the same performance as a true SQL system due to how we store/retrieve stuff.  At the same time layering Pick data into a Row/Table system as Blobs can be an issue.  

Our model of primary key referencing of a "document" is more in line with noSql document databases like MongoDB.   Users of those systems are pushing the same cool features of pick, such as no defined data types, on the fly schema adjusting, complex table structures in a single document.  At the same time they are running into the same issues, locking, concurrency, integrity enforced by the developer not the database, reporting speed.

SQL systems are very good at what they do but their model is totally different than ours.  The great thing about competition is it pushes the other guy.  As multi-value we were never able to convince the SQL group of the power and features of pick but we no longer have to do that, the MongoDB guys are doing it for us.  This is forcing Microsoft and Oracle to pivot and improve their features.  It is adding new open technology such as Rest and JSON that allow us Multi-Value guys to integrate easier.  Here is a link to a very interesting discussion of Shutterfly moving from a Oracle grid where they basically did varchar blobs to MongoDB.  I found it to be a very powerful video that discusses the underlying concepts of the storage engines.  This link https://www.slideshare.net/matkeep/migrating-from-relational-databases-to-mongodb has a very good slideshow showing the schema advantages.

On Saturday, September 16, 2017 at 11:29:51 AM UTC-7, Dawn Wolthuis wrote:

This is both a clarification regarding SQL Server now really being an MV DBMS and also some questions before I head into a meeting with Microsoft next week.

SQL Server is a MultiValue DBMS AND it is the top of the line DBMS for pretty much all other reasons. Therefore, from what I have seen in the industry, for most business applications SQL Server is the best MV DBMS there is. I recognize we need to prove that to some folks, and I'm not certain how best to do that.

Question 1:

If you were to see that MultiValue data stored in SQL Server with the same data available to both SQL (read/write views) and to MV (MV BASIC, PROCS, even ED), what more would you need to know to be 100% certain that SQL Server is an MV DBMS?

For example, 

From the MV perspective: column 1 = @ID, column 2 = @RECORD

From the SQL perspective, single-valued fields become columns, MVs are logically split as new tables from base tables with read/write views of everything

Sure we also have tools to normalize the snot out of the data on the SQL Server side and still do MV reads and writes, but, better yet, you can retain the flexibility of the MV data model by using SQL Server as an MV DBMS, value marks and all, with all of your SQL tools seeing the data as SQL. Both projections of the same data work. That is why the projects to move MV applications to SQL Server are now so successful. SQL Server has a ton of features that support MV data models today.

I probably don't have to show the Gartner Group reports for most IT folks to know that SQL Server is arguably the best DBMS on the market today, certainly among the very best out there for any companies writing new business software applications. The reliability and ongoing admin is extremely impressive, including tools like Always On. Whether looking for 24-8 uptime, scalability, BI/reporting, cloud, or usability, SQL Server ranks at the very top of the DBMS offerings.

One thing it previously lacked was the ability to work well with MultiValue applications. I have heard plenty of horror stories from the days of trying to move from an MV to a relational DBMS. We have been using SQL Server AS an MV DBMS, and it shines. There are Case Studies that prove that MV applications can now run on SQL Server without all of the pain of old migration from MV to relational models. This is a recent one, from the very first site to also use .NET as their run machine with MV BASIC as managed code, so their entire platform is Microsoft. This is even from a formerly SB+ site

http://ongroup.com/web/pdf/case-studies/ABSA-MVONsharp.pdf

Question 2: What would you like to hear or need to hear directly from Microsoft, rather than from me or a site running on SQL Server, so that you know that 

SQL Server is the best MultiValue DBMS on the market today, providing a huge boost in value to the VARs/ISVs and end-customers who trade in their hash table MV for an industry Best in DBMS software?

Thanks in advance for your help on this (and for protecting me from at least two people who are likely to jump all over me for asking such questions in this forum).  Smiles.  --Dawn

Dawn M. Wolthuis

President, Tincat Group, Inc.

EVP, ONgroup Intl

[Patrick Payne]

Sorry, forgot the link to the video.  https://www.mongodb.com/presentations/sharing-lifes-joy-using-mongodb-shutterfly-case-study

[Will Johnson]

What I'm hearing in this is that in order to modify a "multi-value record" you want to be able to hold a lock on that row, in addition to perhaps say half a dozen tables as well.

I just really do not like that approach.  Holding multiple locks in this way, and updating multiple records in series just sounds ready for concurrency problems.

[Steve Trimble]

I have to agree with Kevin on this one Dawn. After updating my Windows 10 desktop (my backup desktop - thank the heavens) , the screen continued to blink / flash. I eventually got it fixed, but it was not a knowledge base article from Microsoft. Obviously I was not in the boat alone.

After 38plus years of PICK/Multivalue, I absolutely love OpenQM on Linux. D3 on Linux is pretty good as well.

As long as I can just program in multivalue and NOT administer, I'm a happy camper. But if I have to administer, it's going to be OpenQM on Linux.

I wish you and the company the best.

be well all,

Steve Trimble

Computerized Data Mgmt Inc

(501) 615-8674 office

[Dawn Wolthuis]

Interesting approach. So, from your perspective are the hash tables what makes MultiValue MultiValue? In other words, is Cache' (using b-trees) also not MultiValue even though it also has a full implementation of MV BASIC and the MV Query language?

Although I was not attached in any marketing way to any MV DBMS product when I did the research for the MultiValue Family Tree, I picked the same thing Jay mentioned with SQL -- the query language, as the base for determining whether a company was an "MV manufacturer." Some of the companies on that chart had the PICK O/S, then PICK was abstracted to a DBMS atop common operating systems like *nix and Windows, so now people think of it as an MV DBMS. 

Nathan Rector at Spectrum wrote about MultiValue now being a framework, so even if one did not want to consider Cache' and SQL Server to be MultiValue databases (although I still don't know why they wouldn't be), all of the tools are there for the MultiValue framework.

So, maybe it is more that the entire solution, in our case with SQL Server and .NET, is MultiValue rather than calling the DBMS a "MultiValue DBMS." I'll think about that. 

The shops that are using SQL Server as their MultiValue DBMS are doing all of the same DCOUNT etc manipulations in their code that any other MV folks are doing with their MV data, so from the perspective of the application, SQL Server is the MV DBMS. From the perspective of those doing BI, however, on that same data, the reporting/BI tool is more likely to view SQL Server as a SQL DBMS. 

So, I guess I get back to the query languages as central to such a definition. If the MV Query language has been implemented with a SQL Server database, that could be seen as an "if and only if" qualifier for defining an MV DBMS. Perhaps tossing MV BASIC in there would help too, but the languages and corresponding data model are key. 

I'm interested in what, precisely people need to see in order to see that as far as an application is concerned, SQL Server is a MultiValue database and an excellent one at that. It sounds like perhaps you would suggest that SQL Server simply cannot be because, well, it is a SQL DBMS and MV is added on? That kindof makes me think of the folks who thought that Prime Information was not PICK / MultiValue because it was added on to an existing operating system.

--Dawn

Dawn M. Wolthuis

Take and give some delight today

[Dawn Wolthuis]

I should have read Dick's response before answering myself. Well put.  --Dawn

Dawn M. Wolthuis

Take and give some delight today

[Dawn Wolthuis]

Yes, it is still going on and quite irritating -- difficult to follow a thread with these rejections inserted. I haven't read through the entire thread, but I'm hoping there is a moderator who will address this.  Tony?  --Dawn

Dawn M. Wolthuis

Take and give some delight today

[Dawn Wolthuis]

You make good points, Ed, including about the full page ad.

I can see someone saying that if there is a third-party product, then the DBMS is not <<whatever>> in essence. However, Microsoft has a means of handling that with certifications. InterSystems Cache' does not have as many third party vendors for you to work with. SQL Server not only provides a solid DBMS out of the box (as does InterSystems), they also provide a means for ISV's and tools vendors to be part of their catalog. So, I would suggest that in this case, SQL Server has features out of the box , such as this one

http://sqlmag.com/sql-server-2016/parsing-denormalized-strings-stringsplit-function-sql-server-2016

That show that it it understands multi-values, and it has C# out of the box. That we have tools written in C# and transpile all of the MV code in the background to C# means that all of the features that MV sites are accustomed to are there -- MV BASIC, PROC, TCL, VOC, PA, MV Query language, etc, using languages native to SQL Server and .NET but the implementation is from a third party (us).

It might not matter technically, but for the purposes of defining MultiValue, I will add that the source code in C# for all of the tools is optionally available, so it is just Microsoft tools that are the platform and then your own application that runs with it. You do not need a 3rd party provider once you acquire it -- a MultiValue application can run on a fully Microsoft platform (.NET and SQL Server) without a Rocket or other MV company in the mix. 

If an application can be run on .NET with SQL Server as the DBMS, then .NET is a MultiValue run machine (p-machine) and SQL Server is a MultiValue DBMS, it seems to me. I hear you, however, that it is not Microsoft themselves who wrote the MV BASIC compiler. Either a 3rd party or the company that wrote the application would have those tools.

More to think about. Thanks.  --Dawn

Dawn M. Wolthuis

Take and give some delight today

[Dawn Wolthuis]

Ok, so by your definition, Wol, I think I hear you say that using our product (an implementation of MultiValue, including the VOC, DICT and DICT.DICT, MV BASIC, MV Query, PROC) is MultiValue, but with this framework combined with SQL Server it does not turn SQL Server into a MultiValue DBMS. 

This sounds something like what Ed was saying that SQL Server could only be an MV DBMS is Microsoft did more than certify the MV framework, Microsoft would have to own the MV framework. So, is this about which company owns what or is there a technical definition of an MV DBMS outside of talking about companies that own them? I would like to think that there is.

Yes, we do have MV data structures fully present in SQL Server. From the TCL prompt it all looks like MV. From the T-SQL standpoint, it looks like SQL. Both query languages are fully present in the full solution, but there are two vendors in the mix, even if only one of them provides the run machine and DBMS platform (Microsoft).

--Dawn

Dawn M. Wolthuis

Take and give some delight today

>

[Dawn Wolthuis]

My impression was that Progress now has the option of using SQL Server as the DBMS or not. Are you working with hash tables or SQL Server or something else with the Progress languages?  --Dawn

Dawn M. Wolthuis

Take and give some delight today

[Dawn Wolthuis]

So, Jay, are you willing to say that whether a DBMS is MultiValue or not depends on the vendors involved or the number of vendors involved rather than choosing more technical criteria for determining whether something is an MV DBMS or not?  --Dawn

Dawn M. Wolthuis

Take and give some delight today

[Dawn Wolthuis]

One of the cool things about SQL Server is that as soon as the MongoDB types started growing out of the open source space, they added in features to be highly competitive. SQL Server was never a pure SQL solution. It is a mutt like so many DBMS products, U2, included. It came from the Ingres branch, where the query language was not SQL (it was Quel). then once out of the academy, there were at least two branches: Sybase and Postgres. SQL Server was previously called Sybase SQL Server. With the great divorce of Windows NT from OS/2, IBM got Sybase and the fork for Microsoft was named just SQL Server. Clever to cut the product name in half that way.

So, it is nice spin to call the MV data model on its own a NoSQL data model. When Ashley, Tom and I came up with the name No SQL (before those who made it famous as NoSQL did I posted it to my blog with a graphic, but it is an MV person who has the nosql.com, .net and .org domains). So, yes, I think the MV model is a NoSQL data model. We named it that. That doesn't mean that SQL Server doesn't support a NoSQL data model better than an MV-only DBMS. SQL Server has a flood of engineers. They moved the product from Quel to SQL decades ago and have JSON and other means of working with NoSQL data structures today.

So, think of UniData as a blend of whatever features its owners have put into it over the years and SQL Server the same way. The question is whether an application and application provider are better served with one over the other. There are few feature sets that SQL Server does't have either on its own or with the vast array of 3rd party vendors. In fact, SQL Server can back an MV application now (using MVON# tools to get you there, that is). That is another way in which SQL Server is both an SQL and a NoSQL DBMS.

--Dawn

Dawn M. Wolthuis

Take and give some delight today

--

[Dawn Wolthuis]

Good, I agree with you. I, too, do not want to define a MultiValue DBMS by how many vendors are in the mix but, rather, by the features it has. We make SQL Server look the same to a MultiValue application as a hash table implementation of MultiValue does. So, yes, it then has all of the features you suggest here.  --Dawn

Dawn M. Wolthuis

Take and give some delight today

[Wols Lists]

On 18/09/17 20:39, Dawn Wolthuis wrote:
> I'm interested in what, precisely people need to see in order to see
> that as far as an application is concerned, SQL Server is a MultiValue
> database and an excellent one at that.

SQL Server CANNOT be a MultiValue database, because we disagree over
what the word "database" means.

As (can't remember who it was) said, an MV database comes with much more
than just the engine. SQL Server is not much more than the engine. In
other words, if we use the word "database" as it is used in the
MultiValue world, SQL Server is not even a database :-)

Stick MVON on the top, however ... but then that is the database PLUS an
environment from a 3rd-party supplier. That would qualify by my
definition, but not by the other person's.

Cheers,
Wol

[Wols Lists]

On 18/09/17 21:02, Dawn Wolthuis wrote:
> Ok, so by your definition, Wol, I think I hear you say that using our
> product (an implementation of MultiValue, including the VOC, DICT and
> DICT.DICT, MV BASIC, MV Query, PROC) is MultiValue, but with this
> framework combined with SQL Server it does not turn SQL Server into a
> MultiValue DBMS.
>
> This sounds something like what Ed was saying that SQL Server could only
> be an MV DBMS is Microsoft did more than certify the MV framework,
> Microsoft would have to own the MV framework. So, is this about which
> company owns what or is there a technical definition of an MV DBMS
> outside of talking about companies that own them? I would like to think
> that there is.

Pretty much.

MVON Express is the MultiValue database. It comes with SQL Server as
*part* of it. That doesn't make SQL Server itself a MultiValue database.

Cheers,
Wol

[Wols Lists]

On 18/09/17 18:24, Patrick Payne wrote:
> While different systems can "emulate" each other (MV can emulate SQL
> with out ODBC layers and systems like Onware and jBase can store MVdata
> in SQL systems as blobs) the actual storage concepts are important.
> While MV can emulate SQL it may not have the same performance as a true
> SQL system due to how we store/retrieve stuff. At the same time
> layering Pick data into a Row/Table system as Blobs can be an issue.

Note that a Relational system can NOT emulate a MV system.

The maths is wrong, and it is *impossible* to translate bi-directionally
between a MV superstructure and a relational engine. A relational
superstructure on an MV engine is, however, trivial ... :-)

Look at the difference between a set and a list ...

Cheers,
Wol

[Dawn Wolthuis]

I completely hear you on that and would not want to have to convince anyone who has used a Windows desktop (pretty much everyone) that it would be good to go to production with a server running such an O/S. I have been convinced both via anecdotes and through reading about Windows servers today that the bad taste I have from Windows NT 4 is in the past and that the desktops are not handled the same as the servers. Most of the personal experience I have with Windows as an O/S would not lead me to using it for production servers.

Since I have worked with linux servers in production since 1994, I'm comfortable with them. However, a site that moved said that they now no longer have all of the version skew and fiddling that they had to do on Linux. So, I'm going with "your mileage may vary" on this. I think that is why Microsoft decided to add Linux as a viable O/S for their offerings. I'm too practical to get into religious wars, plus when people are doing the sys admin work (I, too, dislike such work), they tend to know and like one better than the other. So, let them have their choice. The practical types have convinced me that Windows is as least as good if not better to manage now, but all recognize that for oldsters like me, the taste of Windows NT 4 lingers and my desktop ticks me off just a bit too much to want that in my data center. We have been assured by Microsoft that they will NEVER force automate updates on any servers, by the way. That was essential for us.

--Dawn

Dawn M. Wolthuis

Take and give some delight today

--

[Dawn Wolthuis]

Ah, but MVON is the MultiValue framework and SQL Server is the DBMS, so MVON is not, in this scenario, an MV DBMS. 

I think you are saying that even though MultiValue applications can work handily in this environment, there is not an MV DBMS in the mix. There is an MV framework and there is a DBMS and the application is a MultiValue application, but there is nothing that one can point to as an MV DBMS. In that case, people would be running MultiValue applications entirely without any MV DBMS in the mix. Does that use of the the terms work for you? I don't like it, but I can understand if someone wants to write it that way. Thanks.  --Dawn

Dawn M. Wolthuis

Take and give some delight today

[Glen Batchelor]

I am using the Progress DB itself with the OpenEdge product. The application is Infor SX.e. You can expose the data via SQL similarly to UV. If had a choice of platforms to build a new ERP it would be on OpenEdge.

[Ed Clark]

We just all need to remember that Razzles is *both* a candy and a gum. And I never thought it was very good at being either.

It probably doesn’t matter much how you categorize SQL Server. All that matters is that you let people know that they can include SQL Server in an ecosystem running multivalue applications by adding a set of tools that provide a familiar (and fairly complete) multivalue environment and use SQL Server as the data store. Can you use these same tools with Oracle as a data store? Other databases? How do they handle applications that use 4gls like SB+.

To unsubscribe, email to: mvdbms+un...@googlegroups.com

[Tony Gravagno]

I've disabled the account that is probably responsible for this and emailed the member. If that doesn't solve the problem immediately I'm sure we'll have resolution within a couple days.
T

[Tony Gravagno]

Random thoughts since I'm here...

MV runs over *nix and Windows and Mac. None of these are "MV OS's".
Hashed files can reside in an OS file system - the file system is not MV.
MV environments can RW direct with OS file systems with OpenSeq or direct. That doesn't make MV any less MV.

My point is that the underlying platform is irrelevant. If we run MV in or over some other platform, the definition of the underlying platform does not change, whether it's a DBMS, an OS, a file system, or some bit of hardware like a mobile phone or Raspberry Pi or Arduino.

SQL Server and other RDBMS have their own way of accessing their data. That we run BASIC code which then goes through those mechanisms doesn't change their nature - they are still RDBMS'.

And SQL Server and other RDBMS also have their own notion of multi-value, multi-dimensionality - but that doesn't make them MVDBMS platforms.

This is like the OOP definition of Has-A versus Is-A. With a product like MVON, the RDBMS Has-A MV service, but we cannot say it Is-A MVDBMS.

For marketing purposes, I'd suggest that people who are in the know about SQL Server would object viscerally to having their platform re-categorized. To suggest identity like this is distracting to the purpose of selling to that audience. I believe it's sufficient to suggest that we have an alternative way of accessing data in that well-established and defined environment.

As always, I think tools are irrelevant. If you're going to sell to someone who has SQL Server then it helps to simply say you have a product that works in that environment, like all other vendors. We don't need to have a firm belief in the quality of a platform, and debating the quality of something like SQL Server is purely self-serving, and I think self-defeating. Criticize a platform against the reality that simply is and you get labeled as an outsider. If consumers already have established firm beliefs about quality then our job is simply to deliver what they want, not what we want. This concept has been the bane of the MV industry for decades where MV people think they know better, not offering web, mobile, GUI, or whatever technology in the face of otherwise unanimous consensus that these things are exactly what consumers are buying. Many MV app developers would prefer to go out of business with righteous convictions than to keep up with the times.

We don't need to ride on the coat tails of other offerings, re-labeling them or ourselves. Just sell functionality. End-users want to satisfy their business needs, not philosophize about the MV'ness of a database platform.

T

[Dawn Wolthuis]

The SB+ applications rock in .NET with SQL Server. We migrate them with MVON# (.NET as the p-machine) because MVON (has its own p-machine) is more like OpenQM except that SQL Server is the DBMS.

The MVON# Changeover Administrator takes all SB+ specs over to .NET so they become Netbuilder specs instead. Not only that, the same Netbuilder application runs with a telnet character user interface, a .NET GUI interface and a .NET BUI interface. It is really kick-ass. The CUI is in production in the field while the GUI and BUI are both in the lab and also in current projects in the field.

We are well aware that some have tried other means of migrating SB+ applications and have suffered for the effort. With the few possible needs that a site might have to make tweaks to the source (none we have found in the Avante' application to date, for example), we let you know those up front. It is wicked awesome, thanks in a large part to the brilliance of Grant Hart, the Chief Architect for the product.

The Case Study I pointed to is a company running what was formerly a UniVerse SB+ application. They now run it in .NET with SQL Server as the DBMS. They own all of the source code for the MV layer (MVON#). So, the only platform in the mix of running their application and toolset is from Microsoft. Microsoft is now a player in the MV space.

--Dawn

Dawn M. Wolthuis

Take and give some delight today

[Dawn Wolthuis]

The flea in the ointment is that there is this category in DBTA related to MultiValue. Because this is DBTA, they define some databases as MultiValue and others not. 

I think of MultiValue as a data model or framework. In that case, MultiValue uses a DBMS, much like it uses an operating system. It isn't the database itself. However, I do take your point and that of others that calling SQL Server a MultiValue database in order to have it listed with other databases that support MultiValue applications might not be the best strategy.

Maybe the point is more that just as you don't need a PICK O/S to run a PICK application today, you don't need an MV-only DBMS to run an MV application today. You are not restricted to MV DBMS vendors. You can use some of the most popular databases in the world, as well as the most popular operating systems in the world and run your MV applications there.

When DBTA runs a survey asking about the best MultiValue DBMS, don't you think they are asking for the best DBMS to use with your MV application or that people interpret it that way? In that case, I don't want SQL Server to be left out, just as I wouldn't want Cache' left off the list of options if they asked what the fastest MV DBMS is. It certainly is a contender if not at the top. I'd like to see SQL Server and Cache' tests run from an independent source.

So, yes, I have a specific reason for getting the terminology clarified. It sounds like more people are against calling the DBMS used with an MV application an "MV DBMS." You set up this list with the name "MVDBMS." Do you consider MV applications written in MV BASIC with MV Queries with the data stored in SQL Server as being outside of the scope of the list (say "no" or I shouldn't have asked).  smiles.  --Dawn

Dawn M. Wolthuis

Take and give some delight today

--

[Dawn Wolthuis]

Thanks Tony!  --Dawn

Dawn M. Wolthuis

Take and give some delight today

[Jay LaBonte]

Dawn,

 

No I would not say that it depends on the vendors alone.

 

I don’t think we will ever have an agreement on this issue. The hard MV people are not going to give into SQL being an MV DBMS. What we are arguing here is the same old holy war of SQL vs NoSQL, with MV DBMS clearing in the NoSQL corner.

 

Regards,

Jay LaBonte

[Jay LaBonte]

If we go back to the “original” Pick, then none of the current database are Multivalue in the Pick sense as Pick was first an Operating system. It was then implemented to run as a database environment and eventually became known as the MultiValue Database. Considering how fast technology is advancing and the fact that Multivalue needs to adapt in order to stay relevant, I think it may be time be more dynamic and break out the various layers to determine at which layer in a database Multivalue must be implemented at to make it a Multivalued database.

 

Regards,

 

Jay LaBonte President & CEO   (: 561-705-3688 |*: jlab...@paradigm-systems.us 2234 North Federal Hwy, Suite 1056, Boca Raton, FL 33481 www.paradigm-systems.us

 

 

From: dawnwo...@gmail.com [mailto:dawnwo...@gmail.com] On Behalf Of Dawn Wolthuis
Sent: Monday, September 18, 2017 4:20 PM
To: mvd...@googlegroups.com
Subject: Re: [mvdbms] Re: SQL Server is Now a MultiValue DBMS

 

Good, I agree with you. I, too, do not want to define a MultiValue DBMS by how many vendors are in the mix but, rather, by the features it has. We make SQL Server look the same to a MultiValue application as a hash table implementation of MultiValue does. So, yes, it then has all of the features you suggest here.  --Dawn

To unsubscribe, email to: mvdbms+un...@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

 

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com

[Tony Gravagno]

I tend to dismiss DBTA surveys. They're just more pats on backs within the inner circle and mean nothing outside. You don't need their blessing or to be the best MVDBMS. ONgroup software stands alone in its ability to run MV applications hosted within a completely accepted DBMS. When you're alone in a category like that you no longer need to compete. The challenge at this point is to 1) to get MV VARs to express their pain of trying to pitch the P word when selling their applications, which they shouldn't be doing anyway, and 2) to simply get MV VARs to recognize the value of new audiences that can be approached via SQL Server. "Best" doesn't enter into it if you're the only one who can do that.

Dawn Wolthuis wrote:...

When DBTA runs a survey asking about the best MultiValue DBMS, don't you think they are asking for the best DBMS to use with your MV application or that people interpret it that way?...

So, yes, I have a specific reason for getting the terminology clarified. It sounds like more people are against calling the DBMS used with an MV application an "MV DBMS."

And they are correct. DBMS is a Database Management System. ONgroup products do not manage the SQL Server database Environment. Your products manipulate data stored in a relational database which is managed as any other SQL Server. Nuances about where the lines are between server and data entrench the discussion where it should never go.

When someone administers SQL Server, they are not using MVDBMS tools to do that. ONgroup products are an application over SQL Server, and business applications run over that. You're adding a tier, not changing the identity of the underlying platform.

 

You set up this list with the name "MVDBMS." Do you consider MV applications written in MV BASIC with MV Queries with the data stored in SQL Server as being outside of the scope of the list (say "no" or I shouldn't have asked).  smiles.  --Dawn

No, I'm not saying your products aren't MV. You support BASIC and AQL and all kinds of other great stuff. But I don't believe it follows then that because you are MV that the platform on which you build is also MV. If that were the case then any application could label the underlying OS as some derivative of itself, and that simply doesn't happen.

Best,

T

[Dawn Wolthuis]

I agree, Jay. I have a slide in my deck that shows how MV was originally a data model (data models are implemented by languages, such as SQL or MV). It was implemented as an operating system, and was then called a DBMS (because that was the word for it if running atop an O/S and having persistence). It is now abstracted to a Framework. That framework includes a data model with languages. 

There is a reason I chose the query language as the way of identifying MV in the Family Tree. The fact that MV now runs with a Microsoft platform might not make Microsoft any more "MultiValue" than it makes Linux MultiValue to have MV running on it. It is a DBMS that can back an MV application, however. The concept is more important than the language except in cases where the language is tied to an old concept (e.g. MultiValue as a DBMS instead of a Framework).

Thanks for your thoughts on this. 

--Dawn

Dawn M. Wolthuis

Take and give some delight today

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[Peter McMurray]

Well Discussion is always great.

 

My apologies on the pricing Express typically means cut back however I discover that this is 2014 SQL Server to 10Gb. I am a little concerned that this may be a poor guide given the way MV data is stored in exploded tables in SQL. A Guide to the relative size would be a great help Dawn as a full save on one of my small clients is 3Gb and archiving is an issue over time. An archive is less use if it needs extra paid licenses...

 

I also discover that the game has changed very significantly as of November 2017 with Visual Studio being free open source available on Microsoft, Linux and Apple. The MVOn offering is also free to 10Gb

[Dawn Wolthuis]

I agree that we don't need their blessing, but you can probably imagine why I would like to see SQL Server on the list of options for a company running an MV application.  

International Spectrum "gets it," I think, but I do not have a good understanding of the reach of the different publications.

The future of MV might still have PICK-only O/S's in it for a while yet and surely has PICK-only DBMS's in it, but today companies are running their MV apps without being saddled with old or small platform vendors, and I am researching ways to get that message out.

Thanks.  --Dawn

Dawn M. Wolthuis

Take and give some delight today

--

[Dawn Wolthuis]

Yes, on the small end, just as with folks migrating from Access, SQL Server Express is a good option.  Thanks, Peter.  --Dawn

Dawn M. Wolthuis

Take and give some delight today

--

[Patrick Payne]

Tony, don't forget that jBase has the same feature if you want it. The T24 banking package by Temonos which is on jBase has a bulk of their customers running the database part on either Oracle, Db2, or SQL Server.   It was almost a requirement 10+ years ago to be successful in the banking space as it easily passed auditor requirements and it seems to have worked as Temonos now dominates the European banking market with a Multi-Value application.  The jedi driver allows you to easily map your underlying storage to any other system.  OpenQM can also do this with Martin's Virtual File System handler but I don't think Martin's ships with anything pre-built.

[Dick Thiot]

Well, I must admit that I have never agreed more with Tony.  As we spin this topic back and forth with those in favor and those against, for me whether Microsoft SQL Server should be included in the DBTA survey comes down to a simple question; "Can I run an application that is considered a MultiValue/Pick application on the platform?"  In the case of the MVON# product with a SQL Server database server, the answer is yes.  The amount of conversion required from what I have seen is similar if an application is being converted from one MV platform to another in many cases.

If we look closely at a traditional MultiValue database, essentially all the data is stored in key/value pairs and that is why many of the MultiValue vendors consider them as much a NoSQL datastore as MongoDB, Cassandra or others.  However, SQL Server can adequately store data as a key/value pair and it seems to me that the ONgroup has leveraged this capability in SQL Server to store the MultiValue data.  It is an additional feature that the data is accessible by traditional MultiValue means (MVBASIC, PROC, TCL, ED, etc) as well as SQL Server means include SELECT, INSERT, UPDATE, DELETE, etc.  At this point I don't believe that we are questioning whether it is more performant or how it compares from a licensing perspective, just will it effectively run an existing MultiValue application and can traditional MultiValue developers leverage their expertise in this environment.  The fact that the data is equally accessible by SQL experts is likely an added benefit.

This is not a one size fits all market and as such I do not believe that the product that Dawn is promoting is something that targets all MultiValue environments but I don't believe that any one MultiValue database product is right for each and every MultiValue installation.

We tend to want to prove each other wrong however if we spent as much effort promoting all of the features offered by MultiValue applications whether they run on OpenQM, jBASE, Unidata, Universe, D3, Caché, MVON# or the other MultiValue databases still around then our market might gain more recognition.  I hope that ONgroup is successful at keeping some companies that have MultiValue applications from migrating away from MultiValue and I also hope that they are successful at porting their MVON product(s) to other NoSQL databases whether that be MongoDB, Cassandra or other giving us more platorms to run our applications on.  I propose that we be more open minded to options within our market that grows our market.  For me, the bottom line is that I see the MVON products as keeping some companies running their MultiValue applications.  I have seen companies migrate away because there wasn't an acceptable option when the company executives demanded that the application ran on a more well known platform like SQL Server!

Dick

--

[Dawn Wolthuis]

My understanding is that OpenQM as shipped can persist data to SQL Server. It's in the lab, not in the field that OpenQM can be used as the p-machine with our tools persisting to SQL Server.  SQL Server can be used either as s relational DBMS with normalized columns or as an MV DBMS with key-value in SQL Server. 

This can be done without the jedi driver. I was under the impression that the jedi driver was replaced by Temenos. Do I have that wrong?   --Dawn

Typed on a mobile keyboard

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com

[Wols Lists]

On 19/09/17 00:32, Dawn Wolthuis wrote:
> There is a reason I chose the query language as the way of identifying
> MV in the Family Tree. The fact that MV now runs with a Microsoft
> platform might not make Microsoft any more "MultiValue" than it makes
> Linux MultiValue to have MV running on it. It is a DBMS that can back an
> MV application, however. The concept is more important than the language
> except in cases where the language is tied to an old concept (e.g.
> MultiValue as a DBMS instead of a Framework).

Except that SQL Server is *not* a dbms that can back an MV Framework.

It's an rdbms that is optimised to return rows and columns.

Whereas U2, PI, etc are mvdbms's where the engine is optimised to store
key/value pairs.

Okay, using SQL Server to store key/blob pairs is *just* *as* *good* as
using a dedicated MV engine, but we're not using the strengths of SQL
Server here ... :-) and crucially we are *not* *using* it as a dbms ...

Cheers,
Wol

[Dawn Wolthuis]

I agree that SQL Server does not exhibit this feature set without MVON# in the mix. However, with the MVON# utilities "inside of" SQL Server, I think that by any technical definition SQL Server would then be an MV DBMS. I know you have seen MVON, and MVON# builds into SQL Server beyond what MVON does. 

Now, if anyone wants to define a DBMS based on the number of vendors required rather than on a technical definition, then it would not be, but this group doesn't seem like the type of crowd to want to go that route, so I'm looking for technically what would make for an MV DBMS.

What would you need to see, Wol or others, to be convinced that SQL Server is technically an MV DBMS? If the response is "out of the box," it definitely requires an add-in that makes SQL Server what looks to me like an MV DBMS.

--Dawn

Dawn M. Wolthuis

Take and give some delight today

[Wols Lists]

On 19/09/17 14:57, Dawn Wolthuis wrote:
> What would you need to see, Wol or others, to be convinced that SQL
> Server is technically an MV DBMS? If the response is "out of the box,"
> it definitely requires an add-in that makes SQL Server what looks to me
> like an MV DBMS.

I don't think you could convince me. I'm going to write it up in a new
post, but I'm not sure that there's actually such a thing as a
MultiValue Database Management System!!! :-) It all depends on how you
define the words, and imho the MV and relational people actually use the
words completely differently.

The problems start at the very root - SQL is based on fixed-length
direct access records, MV is based on variable-length random access
records, and it just goes downhill from there ...

Cheers,
Wol

[Tony Gravagno]

Thanks for the ad Patrick, but I didn't forget anything. We're not talking about connectivity TO a RDBMS. Most of the MV platforms can do that via jEDI, VFS, OSFI/OPENDB, etc. (albeit this functionality is hugely under-used). These tools are essentially ODBC clients, connecting to an external data source and passing queries. The data source hosts data in its own native format (in VFS case it depends on how you write it).

We're talking about an MV environment running in and over a RDBMS as an application layer, and in this respect the ONgroup products are unique. They compile MVBASIC to C# which then runs within SQL Server as a managed stored procedure. This is as much "IN" the environment as MV.

And as to data access, they're also closer to the metal. I don't know if anyone has benchmarked, for example, jEDI to SQL Server on localhost versus MVON over SQL Server. I expect MVON to perform much better with most kinds of data.

Where some of the hair-splitting comes in about SQL Server now Being MV, since it can host MV code and data, is that MVON still saves data in the RDBMS in tables and columns as strings, like a dynamic array variable, parsing attributes and values as required. That is not Native storage which is I believe would be required to call any environment truly MV.

Now, does it really matter if we're using C to read from disk and then assembler to SID (Scan Incrementing to Delimiter) parse attributes versus doing a C# .Read() method and then .Split on strings? (or whatever they're doing internally). I'm not that fundamentalist. How we read and parse the data is irrelevant, as obviously all of the MV platforms do it similarly but different.

My contention remains that just because a Tier performs this function, even as managed stored procedures within the environment, doesn't re-define the underlying tiers as being MV. There are many applications that build upon SQL Server like this, but they do not attempt to redefine SQL Server. When we store a frame on disk and do forward/backward links similar to how a native file system would do it, that doesn't make the disk drive "MV", it's low-level MV structures residing in a lower-tier medium - and that's exactly what MVON does with SQL Server.

[Dawn Wolthuis]

Thanks, Tony. You are correct that MVON and especially MVON# are of a different ilk. 

Regarding the use of a single column for multiple values, I think this is correct at a high enough level of abstraction:

1. Salesforce uses Oracle as a DBMS

2. Salesforce data projects (metadata projection) as separate SQL columns for users writing reports

3. Salesforce data is stored as delimited values, perhaps key-value pairs within large columns in Oracle (I know this only from an MV colleague who was in one of their technical classes, I would love to know if there is a URL that describes this)

So, would you say that therefore, Salesforce is not using Oracle as their DBMS or that Oracle is not a viable Salesforce DBMS? Surely they are using a DBMS and that DBMS is Oracle. So, their multivalued (not PICK, not MultiValue) DBMS is Oracle.

As you point out, Tony, there is more going on here. With MVON#, SQL Server does a lot of work compared to what the MV layer or application does.

I have already appealed to a higher power to ask Grant Hart if he considers SQL Server to BE an MV DBMS the way we are using it, and he was in agreement with me that it is as much an MV DBMS as anything else (perhaps more so, as Wol alludes to, given that it has a full database management system, security included)

I'll see if he can explain that in a more technical way than I have.  Grant?  --Dawn

Dawn M. Wolthuis

Take and give some delight today

[Patrick Payne]

Interesting.  I didn't know that was even possible. It was my understanding MVON# was creating c# programs that was running within a .net framework.  I wasn't aware you could do screen I/O work directly against a SQL server via Stored triggers.  

[Tony Gravagno]

I mentioned this in my last post but your note here helps to clarify another angle on this: We're talking about both data and the runtime. These are separate topics.

About data: QM via VFS to a RDBMS will query data in the DB which is stored in common columns and rows. The field definitions (schema) are recognized by anyone who knows SQL. With MVON the data is stored in the RDBMS as blobs. Schema is generated which parses data from the blobs to make it look relational. In this case the database is not being used as MV or relational, it's more like the NoSQL key/value pairs that Dick mentioned.

About p-machine: I think this is another one of those nerdy topics that goes too low for business/marketing. In plain English, a p-machine is a program that parses a stream of text (source code) - call it a compiler, lexical analyzer, tokenizer, or all rolled into one. There is another program, the runtime, that then loops to perform operations based on the resulting tokens. Where this happens is irrelevant, whether it's within or outside of the thread pool of a database. We can assume that within the same thread pool that it should be faster, but that's not a foregone conclusion. And again, running this application in/over SQL Server does not change the nature of SQL Server itself.

T

[Tony Gravagno]

The screen IO part is just a separate telnet application. The engine itself is indeed managed .NET code within/over the SQL Server environment. I've written code like this to get processing closer to the metal, and avoid pulling bulky data across a wire to process it. There are special considerations for making it work but the code isn't much different from any other C#/DB code.

T

[Patrick Payne]

Thanks for the clarification Tony.  As to the original thread that veered heavily into the storage layer and not the runtime layer which can be another whole thread I wanted to clarify that point.  On jbase we have separated these two and do allow any other storage system to be plugged in.  We have built in Jedi drivers to Oracle, DB2, and SQL server and we have many large customers using this technology and are very happy with it.

[Tony Gravagno]

 Dawn Wolthuis wrote:

So, would you say that therefore, Salesforce is not using Oracle as their DBMS or that Oracle is not a viable Salesforce DBMS? Surely they are using a DBMS and that DBMS is Oracle. So, their multivalued (not PICK, not MultiValue) DBMS is Oracle.

Dawn, within just a few sentences here you're crossing definitions. Above you define Salesforce Using Oracle, and then below you translate that into SQL Server Being MV. You can't ask a specific question and then blur the definition alternatively in the discussion.

Oracle is NOT a Salesforce DBMS ... whatever that means. The nature of Oracle does not change based on how it is used by an application.

SQL Server is NOT a MV DBMS based on how the MVON application stores and accesses data.

Yes, Salesforce and MVON Use these RDBMS platforms in exactly the way they were intended. That does not redefine their nature. Trying to pitch this concept to anyone who understands the topic will immediately derail whatever pitch you're trying to make. You have so much to talk about with MVON. It's a great product. I have no idea why you want to go down this path of identity when no other product does this in the course of its Marketing and Sales efforts.

What is the purpose of this line of inquiry? To whom do you intend to pitch these concepts? I believe you mentioned Microsoft in the OP. I dread the notion that this would become a point of contention in such a meeting, a rat hole to suck up valuable time that's needed to convey product benefits and to describe a potential wealth of applications that could run over this fine platform.

T

[Dawn Wolthuis]

Was trying to give an analogy that relates to what you said. All analogies are flawed, but some are useful. Apparently this one was not.  Withdrawn.  --Dawn

Sent from my iPad

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com

[Grant Hart]

To unsubscribe, email to: mvdbms+un...@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

Sql Server as a MVDBMS

 

Wikipedia describes a database as:

Formally, a "database" refers to a set of related data and the way it is organized. Access to this data is usually provided by a "database management system" (DBMS) consisting of an integrated set of computer software that allows users to interact with one or more databases and provides access to all of the data contained in the database (although restrictions may exist that limit access to particular data). The DBMS provides various functions that allow entry, storage and retrieval of large quantities of information and provides ways to manage how that information is organized.

Because of the close relationship between them, the term "database" is often used casually to refer to both a database and the DBMS used to manipulate it.

 

 

With the above definition we could describe a Multi Value database as consisting of the following:

 

1. All mv databases store their data as a key value pair, depending on the flavor, some use frames, some use flat files and most use a hashing algorithm to store the unstructured data in underlying file system.

2. What differentiates MV databases from Sql databases is the way data is interpreted. All mv dbms have an engine that can extract and relate attributes, values and subvalues via dictionary definitions. This is dynamic and does not need to be pre defined in order to store data in the database. Sql dbms have a predetermined schema and strongly typed data.

3. All MVDBMS have a variety of tools that interact with the data like BASIC, PROC, F Correlatives, Itypes etc.

 

Simply using a Sql engine as key value datastore does not make sql server a MVDBMS, simple just another storage mechanism for multi value data. Some mv platforms like jBase can use sql engines as a datastore and using techniques like storing the data XML, can utilize some database engine functionality like XQUERY to process the mv data.

In order to claim Sql Server as a MVDBMS, the Sql engine needs to be able to extract and relate attributes, values and sub values within it’s own engine to qualify as a true MVDBMS.

Products like jBase, Universe and OpenQM have extensions that allow alternate key value stores to be used as a datastore. This does’nt make the alternate store a MVDBMS as the data is still transferred from the store and processed in their own mv engine.

 

So what makes Server Server a true MVDBMS when used with MVON# tools.

MVON# Sql Extensions is a C# engine that is embedded into a Sql Server instance to fully implement a MV engine. This means that the relating of MV data like attributes, value and subvalues is processed inside Sql Server and not simply passed to another MV engine for processing.

To fully comply as a true MVDBMS, this engine also needs to be able to implement MV style data processing. Itypes, Conversions and  F Correlatives. All this MV functionality has been implemented in MVON# Sql Extensions.

 

Example:

SELECT CUSTOMER WITH FNAME Like “MV…”

Where FNAME dictionary is

D

3

 

First Name

20L

S

Would translate to the following in MVON# Sql Extensions

 

Select Id From CUSTOMER Where dbo.getUvAttribute(id,Array,3) Like ‘MV%’

The above example is just a small part of the Sql Extensions. It also allows us to create Sql Views on the multi value  data that is dynamically normalized on the fly and presents your MV database as a fully normalized database to the Sql Tools world. These views are also updateable allowing technologies other that BASIC/PROC to create and update MV data.

 

 

 

[George Gallen]

I've tried to read through as much of this as I can.....

From what I'm seeing is that we in the MV world are spoiled in that the programming language and the database query language

   are both in tune to working with multi-valued fields.

I've been using MSSQL to function with multi-values for a while with php - I just had to write my own functions to pull a

value from attribute x, or insert or delete or whatever. But in the end, it's still just a string with a unique delimiter when stored,

and I add the delimiter to the front and end of the string as well so I make a unique "like" so  /car/ wont hit on /cart/ with

the like in the query line. However my php routines ignore the first and last delimiters from it's attribute counting.

and on the MSSQL side you have use like ... instead of an = as the MV DBMS understands it's multivalued based on the dictionary

So, is MSSQL actually allowing you to define a column as being multi-valued and the = 'xxx' will search each instance?  but what does

it return in the select field from table? just the piece that matches? and will it automatically create multiple selection lines as if

there was some magical JOIN of a child table involved to still give a normalized flattened output?  (similar to the WHEN clause in MV).

George

[Dawn Wolthuis]

One small point here, George is that it would NOT seem to me to be a MultiValue DBMS if SQL Server had a type for a multi-valued field. SQL Schema are prescriptive. MultiValue schema (with DICTs) are descriptive. The DICT is in SQL Server as a descriptor for use with MV queries where the SQL Schema is used for SQL queries. Make sense?  --Dawn

Dawn M. Wolthuis

Take and give some delight today

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[Tony Gravagno]

Thanks Grant, follow-up below...

On Tuesday, September 19, 2017 at 11:36:33 AM UTC-7, Grant Hart wrote:

Because of the close relationship between them, the term "database" is often used casually to refer to both a database and the DBMS used to manipulate it.

 

Simply using a Sql engine as key value datastore does not make sql server a MVDBMS, simple just another storage mechanism for multi value data. Some mv platforms like jBase can use sql engines as a datastore and using techniques like storing the data XML, can utilize some database engine functionality like XQUERY to process the mv data....

MVON# Sql Extensions is a C# engine that is embedded into a Sql Server instance to fully implement a MV engine. This means that the relating of MV data like attributes, value and subvalues is processed inside Sql Server and not simply passed to another MV engine for processing.

To my understanding, you Are storing your data in relational tables, accessing the data via relational schema, and processing the MV data as described above. If that is not the case I'd like more education on that.

Ultimately, we're not talking about a casual reference to database versus the DBMS which supports it. In a thread like this where the question is specifically put to redefine a RDBMS as a MVDBMS, we need to be quite specific about what that means. It's my contention that your code is using the RDBMS as-designed, that it uses the functionality built-in to it to allow you to do what you do. That doesn't re-define the facilitating platform. An admin still needs to administer the SQL Server DBMS just like any other SQL Server system. That includes permissions, thread pooling, and all of the things that SQL Server people recognize as management of a database _environment_.

T

[Dawn Wolthuis]

Tony -- please note that I'm not trying to redefine an RDBMS to be an MVDBMS. I am treating the DataModelsSupport field (DATA.MODELS.SUPPORTED?) as multi-valued. It is a DBMS that can be used as both a relational and MultiValue database management system.

 

--Dawn

Dawn M. Wolthuis

Take and give some delight today

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[Grant Hart]

Hi George

Part of the Sql Extensions is a function in sql server  "compareMultiValue" this will expand the multi values in an attribute and then return only the id's that meet the criteria. In the case of a BY-EXP query there is a scalar function "ExplodeMV" that returns the mv position as well as the Id's.

Hope this explains your question

[George Gallen]

Are there other extensions to insert/delete a value from a mutlivalued attribute as well?

and can you specify which level to insert at or delete from - and do the other values drop similar to the DEL<>

that was the problem If I recall from Mongo when you removed a value it didn't adjust the attribute

and you could only add to the end (granted, this was early on in their release - and I haven't really looked at

it since).

So i'm seeing the extensions as my php functions except within MSSQL as T-SQL

I can see that was being useful, if you don't want to have to keep creating libraries for each language you

access from, just have a standardized sql statement...

George

---

From: mvd...@googlegroups.com <mvd...@googlegroups.com> on behalf of Grant Hart <gran...@gmail.com>
Sent: Tuesday, September 19, 2017 3:28 PM
To: Pick and MultiValue Databases
Subject: Re: [mvdbms] Re: SQL Server is Now a MultiValue DBMS

 

--

[Glen Batchelor]

You can treat all character data fields as multi-valued or multi-dimensional simply from an application usage perspective regardless of how the data is stored below the data assignment layer. We do that with Progress and ABL is designed with field-level lists as a normal formatting method. It is considered a relational DBMS and DB. The field layout has predefined user fields with fixed length chars but the lengths are only descriptive and you have unlimited (up to the DB storage limit). We use comma, pipe or caret delimiting in flag and value lists the same way Pick hashes values.

Glen

[Grant Hart]

Hi Tony

In MVON# we are actually storing the data as key value pair in Sql Sql Server. This has the major advantage of not having to verify strong data types  before persisting rows to the database giving massive performance we also see in the MV world. However access to the data is via our MV engine that is embedded into Sql Server. All selects, itype processing and F correlative processing is handled by the Sql extensions.

We are effectively doing what a MV engine does to the data in other MV platforms but Sql Server is actually doing all the processing. Added to this we expose the data to the non MV world as a normalized database dynamically from the key value pair.

Hope this explains it a bit better

[Grant Hart]

Hi George

MVON# exposes multi values and related multi values as a view to the sql environment. These views are updateable and so from a sql perspective you could issue a statement like

Delete From Customer_address where Id = '1000' and Row = 2

Where Row = 2 determibes the 2nd multi value in the address view which is a multi value field in the Customer file

Hope  this helps

[George Gallen]

Hi George

MVON# exposes multi values and related multi values as a view to the sql environment. These views are updateable and so from a sql perspective you could issue a statement like

Delete From Customer_address where Id = '1000' and Row = 2

Where Row = 2 determibes the 2nd multi value in the address view which is a multi value field in the Customer file

Hope  this helps

So....if it's being stored as a set, data and row#, deleting row 2, would not make row 4 now 3 and row 5 now 4 as that would require updating the row# of any

sets that followed the deleted value?  or is the row # calculated on the fly from view and stored with the data in the actual field?

George

[Tony Gravagno]

You've misunderstood that reference. I meant redefine a specific RDBMS as an MVDBMS, namely SQL Server. I wasn't implying that you're trying to redefine the concept of relational as multi-value ... c'mon now...
The title of this thread is, after all, "SQL Server is Now a MultiValue DBMS".
Again, the difference in opinion here is about IS versus Has or Uses or Supports.

Thanks.
T

[George Gallen]

I agree what Tony is saying, which is what confused me - not realizing it was an added extension to MSSQL vs intrinsic to MSSQL

But...to the average person who knows nothing about mutlivalued - it just semantics. but I see your point.

George

---

From: mvd...@googlegroups.com <mvd...@googlegroups.com> on behalf of Tony Gravagno <bacj8...@snkmail.com>
Sent: Tuesday, September 19, 2017 4:22 PM

To: Pick and MultiValue Databases

Subject: Re: [mvdbms] Re: SQL Server is Now a MultiValue DBMS

 

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com

[Grant Hart]

The row number is based on the underlying data set and is calculated on the fly.

[Dawn Wolthuis]

I wasn't implying that. I was implying that SQL Server can be both a SQL DBMS and an MV DBMS. We can make our mental field that I'll name DATA.MODELS.SUPPORTED and MV field. SQL Server now supports both models, and we have the utilities that turn the SQL Server engine into an MV engine as well as a SQL engine.

Dawn M. Wolthuis

Take and give some delight today

[Tony Gravagno]

I'll thank you for your explanation and gracefully back out of this discussion. I still am of the opinion that adding an application to a system to do something does not change the identity of that thing, and there are a million examples to support that position. I don't believe it will serve your business needs to pursue this specific vector of messaging. It's too controversial, too digressive. It's the big word in a sentence that no one recognizes that causes the reader to stumble on the content. It's that moment in a movie that breaks the suspension of disbelief. Profit! << See? I just did it too and it destroyed whatever it was that I wanted you to take home. You don't need that.

Best as always,
T

[Tony Gravagno]

Which reminds me - I monitor StackOverflow for questions about the MultiValue DBMS. It's quite common for people to ask about multi-valued fields for various RDBMS platforms, and to tag it as MultiValue, which I then correct. To them, they do support multivalued fields, but they are not what we call MVDBMS platforms.

Once again the lack of attentive and assertive marketing in this industry has caused us to miss the train, as RDBMS and NoSQL people sought and now regularly use multivalued data in their applications, we've completely missed years of opportunities to tell them that we've had it for decades.

T

[Grant Hart]

Absolutely agree with you Tony,

The value is not in the fact that our data is MV, the value is in the millions of lines of code (IP) that is servicing 1000's of businesses around the world. The ability to deliver business solutions quickly using our model has always been our advantage but sadly not delivered to the corporate world very well.

Grant

[Dawn Wolthuis]

Thanks Tony, Note that I asked questions. I very much appreciate the answers, and I agree with you that even if technically the combination of SQL Server plus the MV features in our SQL toolkit turn it into an MV DBMS by almost every possible definition, that might not be a good marketing strategy. I wanted to be sure we are dotting the i's on the technical front first, and it seems that we have from most perspectives (other than the 2 I mentioned -- single vendor -- not a technical requirement, and hash tables -- not true for all current MV DBMS products).

We have a group of highly technical people in ONgroup Intl, with me being the most marketing-ish of any of them (and my masters degree is in Mathematics, so I'm not exactly groomed for that either). I'm looking at how to get the word out without hiring a fleet of marketing pros and sales people. The interest is high, and we want to put our resources on the technical side if feasible, so we can fulfill the Proof of Concept projects and implementations that people bring our way. 

Ideally, it would be nice to have the Microsoft platform we use very clearly make the list of viable options in the MV community.

MVON# has .NET as the run machine, backed by industry standards, etc. The run machine is the CLR, Common Language Runtime, and we allow MV BASIC to be another language whose "p-code" runs in this "p-machine". It is bar none, the finest run machine in the MV space. Agreed?

MVON# uses SQL Server as the DBMS, and we turn it into what looks to us to be an MV DBMS by every practical measure. So, I wanted to know what people would need to see to verify that SQL Server is now an MV DBMS.

I hear you saying not to go there on the marketing side. I'm not writing marketing copy here, just trying to get some suggestions on what would convince people that when Spectrum or DBTA have a list of viable MV DBMS's, SQL Server is also known to those reading the list as a viable option. I'll think about it some more and very much appreciate the input.  

Thanks.  --Dawn

Dawn M. Wolthuis

Take and give some delight today

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[Dawn Wolthuis]

I had to read that 3 times to get that the "we" was not you and me and our ONgroup team, batman. Yes, agreed, "we" the MV world has had some difficulties with that. However, we were also instrumental in getting NoSQL data models out there, which is why SQL Server and other mainstream DBMS products are so easy to use with MV today. 

SQL Server supports pretty much anything anyone wants in a DBMS today, with few exceptions. So, in a way, we have brought MV right into the mainstream. In fact, I dare say that you, Mr. Hart, have done some amazing work to make that happen.  Cheers!  --Dawn

Dawn M. Wolthuis

Take and give some delight today

--

[Dick Thiot]

Dawn,

I am not sure that SQL Server should be included in the list from a DBTA perspective.  ONgroup uses SQL Server to store the data but that does not make SQL Server in and of itself a MV database system.  I think that DBTA should recognize ONgroup as a vendor in the list but not SQL Server.  Sorry if that doesn't fit your plans of leveraging SQL Server's acceptance in the marketplace.  The VARs in the market than can benefit by deploying their application utilizing SQL Server as well as any large companies where the IT staff is having to justify their use of the MV database in the face of management wanting to migrate to a more industry excepted platform could certainly benefit from your products.  You have made the point that ONgroup does not need to be in the mix since the customer can purchase the source code.  However, while they can purchase the source code does not mean that your product is not required in order to accomplish running MV applications using a SQL Server datastore.  OK, I admit, that your product makes SQL Server much more than a datastore but without MVON/MVON#, the MV application does not function.

Dick

[Dawn Wolthuis]

Good points, Dick and others. I'm collecting them all. 

Even if the combination of SQL Server plus MVON# surely is an MV DBMS by almost every technical definition, I take the point that SQL Server on its own would not pass any MV tests, were there to be any such criteria.

There are many accurate statements that say something similar:

1. SQL Server and .NET together provide a DBMS and run machine, i.e. the platform, for MultiValue applications, using the MVON# toolset

2. Were there to be a Gartner Group magic quadrant for MultiValue platforms, Microsoft would be there at the top

3. Microsoft is now a vendor for the DBMS as well as the run machine for MultiValue applications

So, without calling it an "MV DBMS" if that is too disturbing to people even when the only criterion it fails is the one-vendor criteria, nothing technical, there are ways to make less controversial statements like these. Controversy is my middle name, however (a clear indicator that I'm not a real marketing person, right?)

I'll work on it. Thanks. --Dawn

Dawn M. Wolthuis

Take and give some delight today

[stope19]

On Wednesday, 20 September 2017 11:58:09 UTC+10, Dawn Wolthuis wrote:

Good points, Dick and others. I'm collecting them all. 

Even if the combination of SQL Server plus MVON# surely is an MV DBMS by almost every technical definition, I take the point that SQL Server on its own would not pass any MV tests, were there to be any such criteria.

There are many accurate statements that say something similar:

1. SQL Server and .NET together provide a DBMS and run machine, i.e. the platform, for MultiValue applications, using the MVON# toolset

2. Were there to be a Gartner Group magic quadrant for MultiValue platforms, Microsoft would be there at the top

3. Microsoft is now a vendor for the DBMS as well as the run machine for MultiValue applications

So, without calling it an "MV DBMS" if that is too disturbing to people even when the only criterion it fails is the one-vendor criteria, nothing technical, there are ways to make less controversial statements like these. Controversy is my middle name, however (a clear indicator that I'm not a real marketing person, right?)

I'll work on it. Thanks. --Dawn

<snip>

I'd accept point 1, in that the MS products 'enable' the implementation of the MVON product. Point 2 is just a matter of opinion/conjecture. Point 3, I (speaking only for myself) don't accept. Microsoft is the vendor of the SQL Server/.Net products. MVON (if that's a company name?) have used these products to implement theirs. Nothing more. And don't be hard on yourself, you seem to be a 'natural' for marketing. :)

[Dawn Wolthuis]

Ha, thanks, I think. Because I doubt there is as much controversy, even if differing options, about a "platform" compared to a "DBMS" I'm really curious why 3 doesn't resonate with you. 

Our MVON# toolset is just that. It is a toolset that allows an application written in MV (even those written in SB+) to persist data using SQL Server and run in .NET. That is a Microsoft platform. You use our tools to transpile all MV source code to C# (you can ignore the C# or inspect it) so it all runs in .NET.

So, either I am saying something wrong that looks obviously right to me, or I have not explained ONgroup's MVON# tools well enough. Did this help get you on board with the wording or 3, or what would you need to see or hear to groove with that description?

Thanks.  --Dawn

Sent from my iPad

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com