frosty wrote:
How about

DBMS:
A Database Management Systems is a product consisting of tools to
create and manage one or more databases. A DBMS is likely to include
some, unlikely to include all, of the following features:

1. tools for specifying metadata
2. tools for developing functions or stored procedures
3. triggers
4. constraint handling
5. a query language
6. utilities for performance tuning
and so on and so forth and scooby dooby doo (tons of possibilities for
this list)

Cheers! --dawn.

Our "Client Prospecting System" is called "Shovel" - catchcry used to
be

"Pick and Shovel - the best tools for prospecting"

Doesn't have the same "ring" to it with D3 --> then again, 'back then'
we WERE called "pickworks"

Ross Ferris
Stamina Software
Visage > Better by Design!


frosty wrote:

frosty wrote:
***NEWSFLASH***+++***NEWSFLASH***+++***NEWSFLASH** *

no

I can't reasonably see why any of the MV products can't be described as a
Database Management System. I can't think of a definition that they fail
by...

Certainly, the all provide the tools, utiliies and means to design, store
and retrieve data....

I wouldn't go so far as to say that they are RDBMS's though - they are
certainly *not* relational. Though I suppose that as Multi-values are added
to RDBMS's and the definition of what constitues "relational" is modified to
cope then the "MV" databases will fit the definition more closely. The core
item we are missing is the forced definition of the data structures.
Referential integrity and data typing are also closely related issues...

Regards
Simon

--
================================
Simon Verona
Dealer Management Service Ltd
Stewart House
Centurion Business Park
Julian Way
Sheffield
S9 1GD

Tel: 0870 080 2300
Fax: 0870 735 0011

"Mike Preece" <michael (AT) preece (DOT) net> wrote

Dick Pick never liked sub-values. He told me if "you need sub values, you
didn't know how to design a database."

And he said, if you left off the multiple values of an attribute, you'd have
a relational database. Something about being able to find any data by an
x,y vector for row and column. He said, Pick just added a third dimension
that the original flat worlders never imagined. So we have to call pick a
Post-relational Database.

Once Pick was the operating system, and you can't get much more DBMS than
when you control the enitre OS. Now, as a blister on the back end of Unix
or Linux or Windows, the ONLY thing we control is the database.

So, yes, by just about any definition that doesn't stick annally to some
outdated dogma, the Pick model is a DBMS.

Mark Brown


"Simon Verona" <nomail (AT) nomail (DOT) zzz> wrote

Mark Brown wrote:
I only wish he'd printed that in the programmers' manual. In bold type,
on the cover. <g>

That said, I have had one use for subvalues that I considered valid, in
a b-tree indexing tool.

A telling thrust! I smell blood. <g>

Luke

Mark Brown wrote:
I so love that anecdote! I, too, think that it is not a good design to
go deeper than to multivalues. This is a point where theory fails us.
We have one theory (the out-dated version of relational theory) that
says that you want no nesting. You have products like Cache' and
apparently Visage that permit very deep nesting. On what theoretical
basis would I want to stick to only multivalues, not 1NF and not
sub-values? I dunno. It is a practical matter, it seems. Just as
writing sentences with lists within lists is not common, so too the
modeling of such sentences is too convoluted when there are lists
within lists.

If anyone has more clues on why a best practice might be to model with
lists, but not lists within lists, let me know.

No papers about the relational model had been published at the time
when Nelson designed GIRLS. I feel pretty confident that Pick is
pre-relational. I do think it is a data model similar to what will be
post-relational, however. I think that the 1NF of the relational model
has been an unfortunate deviation for the industry. Hopefully it will
get back on track again.

Although some will say that then you "just" have a file system.

agreed. Cheers! --dawn

dawn wrote:
Please be aware that the reason Vsiage initially supported "deep
nesting" was because we have clients, with well established systems,
software & procedures, that had data nested upto 5 levels.

As we had to "solve" the problem at this level, it wan't such a big
deal to extend the recursion a few more levels.

As to "best practice", I'm still in 2 minds. As with multi-values, the
"advantage" is that you perform a single read of a recrd and (can) get
all related information. We actually DO use this now when a Visage
process is defined Visage :

A process can have many pages or screens (multi-values), and each
screen can set "traps" for various actions or messages
(sub-multi-values). Each "trap" can then cause a number of subroutines
to be called (sub-sub-MV), and each subroutine can have many parameters
passed/sub-stituted (sssMV) with values from the process. (The map of
nested relations/associations is defined as part of the file meta-data,
so we have a "hook" that would allow us to map associations out to a
differet physical structure if required, and this also plays a part in
XML generation)

This seems to work well for us, though there are obviously many
alternate "flatter" structures, but the number of screens/message etc
is reasonably small within a single record, so the advantage of a
single read "wins"

I'm looking forward to "playing" with the Cache facilities in this
regard, which I understand are more intrinsic to the native DBMS
environment

As an aside, I was sorry to see WinFS "cut" from Vista roadmap - given
the SQL(-like) built in capabilities, and "natural" nesting
capabilities of a hierarchical directory structure, this showed some
promise as a data repository .... but I digress