OT: What makes a DBMS multi-valued

[Walter Vaughan]

Fairlight wrote:

> Apparently my lack of -formal- DB training is showing.  I understand about
> 1/3 of what they're trying to convey.  Okay, let me ask this--how are MV
> databases "bad"?

[make sure you are reading this with fixed width fonts]

How about what makes them good to begin. However one man's good is probably 
another's bad. Given the following header/detail:

HEADER
Order# 	Date 		Customer
1001 	12 Jan 05 	1728
1002 	12 Jan 05 	3194
1003 	13 Jan 05 	7532
1004 	13 Jan 05 	1263

DETAIL
Order# 	Item# 	Quantity
1001	107 	4
1002	318 	2
1002	452 	3
1003	220	1
1004	318	2

Multivalue database products remove the need for normalization by allowing a 
single cell of a table to hold more than one value. In the following example, 
each Order# is a different record, yet if you look carefully order 1002 has two 
different products in that record

Order	Date 		Customer	Product	Quantity
1001 	12 Jan 05 	1728 		107 	4
1002 	12 Jan 05 	3194 		318	2
					452	3
1003 	13 Jan 05 	7532 		220 	1
1004 	13 Jan 05 	1263 		318 	2

Taking it a step further you could go one step further and allow the values to 
be further divided into subvalues.

Order# 	Date 		Customer   Product	Quant	Serial No
1002 	12 Jan 05 	3194	   318		2	15273
							15283
				   452		3	3728
							3736
							3436

Remember all of that data is stored in a single record, and you can add as many 
multiple values and subvalues as you need. There are no record pointers, so 
fields can expand and contract as wide as needed, and indexes don't care.

What even more interesting is that the procedure language is stored as records 
as well in the database, it is quite easy to write self modifying code if you 
want. And since the first applications of this were in Military and Government 
contractors, security is scalable from weak to particular fields in particular 
records with regards to read/write access by user/group/etc...

IBM seems to taken leadership in this arena and is supplying pretty good tools 
to take it's MV databases into the 2010's and beyond. And multiple job openings 
with skills in these systems seem to be opening up daily nationwide, so skills 
are transportable to a wide variety of employers.

What's bad?

They suffer from the same graying of the population like filePro. Maybe even 
more so, since the system has been in use since the 1970's. And while there are 
easy to install "Personal Editions", there is no tutorials like we had with 
filePro back in the small computer days. So unless you know it already, or plunk 
down thousands of dollars for a class, the chances of you learning it today are 
slim and none.

--
Walter, who will not be implementing a MV solution, but was and is quite 
impressed by the technology.