Re: Good Books on MultiValue Databases

Trisha Ford wrote:

So I don't think I was trying to claim to be an authority at all there.

It looks like we're on the same page. I tend to see "this is what I
know so this is the way it is" comments in these forums all the time
and I just took this opportunity to make an observation. Nothing
outside of this was intended.

However, in the end regardless of whether
converting manually or using a tool, ultimately the end result is
still the same and you are, in fact, "re-architecting your entire
database". That is, either you are, or your tool is.

Well, yeah, a migration is a migration. If you completely migrate
your data, schema, and rules into a completely different environment
then it must be restructured. What I was reading from your comments
(and similar comments from others from time to time) is that a
migration "necessitates" a lot of manual mapping. This isn't
"necessarily" correct considering the various solutions I proposed for
either schema mapping or using SQL against existing databases where
SQL can be run against a virtual schema definition. (Maps that look
relational vs physical relational structures.)

Again, since MV
data is by definition in violation of the 12-Rules of true RDBMSes (no
new info there, right?), the database structure when converting from
an MV environment to an RDBMS actually does require re-architecting.

I'll buy that to an extent. Your point is simply that MV is not
relational. No disagreement.

Once again your comment about Codd borders on another topic which I'll
tackle, (and I'm not saying you're saying this) that MV is somehow
invalid because, so they say, it doesn't fit Codd's rules.

As always, the very first (make that "zeroth") of Codd's rules stacks
the deck by stating "the system must qualify as relational". That's
like saying all motor vehicles must be fueled by gasoline which makes
it illegal to drive an elecric car on a roadway designed for motor
vehicles. No reflection on you at all Trisha, but relational people
tend to debunk MV (and XML and object and post-relational) data models
with this sort of circular rhetoric. The TPC benchmarks disqualify
non-relational databases by explictly defining how the relational
tables will be defined - um, if we don't have relational tables then
we can't possibly create a "valid" benchmark.

Let's take a look at a couple of Codd's other rules:

Rule 1 "All information in the database is to be represented
in one and only one way, namely by values in column positions within
rows of tables."
Well now if a "better" database ever comes along is it invalid
because it breaks this rule? Yup. Codd wrote his rules specifically
to defend his position on relational databases. Somehow this got
warped over the years to imply invalidation of anything that didn't
fit the definition.

Rule 3: "The DBMS must allow each field to remain null (or
empty). Specifically, it must support a representation of "missing
information and inapplicable information" that is systematic, distinct
from all regular values..."
Different RDBMS platforms support Null differently. Does that
make them non-relational or invalidate them as relational? Given the
definition of null, of course MV doesn't make this distinction on its
own, but with reference to my comments on how important business rules
are, we maintain referential integrity in MV not as a built-in part of
the DBMS, but the dbMS which includes a DB allows us to do this at the
code level. Similarly we're allowed to handle nulls as we see fit,
and many applications are coded to recognize the difference between
"no data" and "data is empty string". So because we use the tools in
management system, rather asking the management system to manage
itself, do we really violate this clause?

Rule 4: "The system must support an online, inline, relational
catalog that is accessible to authorized users by means of their
regular query language. That is, users must be able to access the
database's structure (catalog) using the same query language that they
use to access the database's data."
It seems this rule is really two in one: (a) users must
authenticate to get rights to access data, and (b) data and schema
must be accessible via the same query language. We can restrict user
access via login and command line lockouts. And we can say "SORT DICT
FNAME" as easily as we say "SORT DATA FNAME". Looks to me like we're
as compliant as anyone else...

I could go on about each one but I'll spare you more detail. (Haha,
funny thing for me to say.) It's possible to cite various RDBMS
products that by design or flaw do not conform to some of Codd's
rules. It's similarly possible to show that the capabilities of the
MV Database __Management_System__ allow us to Manage our data in a
manner consistent with most if not all of Codd's rules. The
distinction of the symantics may be lost in my inept ramblings here
but I think it's important that we have the freedom to make or break a
good app, and this is where relational people confuse open
(freedom/liberty) access with lack of ability. That is - we can,
though sometimes _do_not_, write code to enforce good relational
practices, but they say we _cannot_. This is why people throw Codd in
our faces, because their definition of the managment system is that
the system manages the data, but our definition is that we manage the
data using the system.

When computers were first created people feared they would control the
world, and science fiction is full of machines that make slaves of
man. While we all look at this as silly fantasy it's amazing how much
people rely on the machines to do things like data management for us
and how sternly they frown upon those of us who prefer to have more
control - because we enjoy such freedoms. Our choice to use software
which allows us these freedoms is criticized with references to these
rules of Codd which insist that the machine not only do something for
us but do it the way this one guy wrote oh so many years ago. The
Pick model has been slighted as being old and therefore wrong simply
on the premise that Codd wrote his rules after Pick. This is just
another example of the lack of logic some people employ to justify
their positions.

I'm not saying Codd's rules are necessarily wrong, that Pick is
better, that Pick is relational, etc. That's not the argument I'm
making here. I'm saying it's only valid to cite Codd when you're
trying to decide how conformist a relational database is to relational
rules, not when you're trying to validate whether or not a data model
is suitable for its intended business tasks.

Again, Trisha, I know you were just saying MV is different enough to
warrant some major changes.


I say this with the possible exception being that if you were not
using Sub-Values anywhere in your MV database to begin with, then you
may not need to re-architect in that case. Although clearly that
would be a great waste of the MV features in the first place.

Not necessarily. I think most applications I've seen actually do not
make use of sub-values. One reason is that the data isn't accessible
to most query processors. Another reason is that the logic is just
too complex and it promotes "hot shot" coding where a bit of (ahem)
normalization is actually better for maintainability.


Then again I can't remember the last time I've seen relational key-
constraints actually implemented in any of the RDBMS DBs I've
supported in the last (I'm not telling how many years). >:-) Keyword
there being that I have "supported", not architected.

That's funny considering the major focus people put on the RI aspects
of the relational model- can you explain this a little more?


Excellent point as well on getting sucked into the
"hey let's re-engineer our application on the fly" during conversion
efforts. That would fall into your basic Scope-creep though, yes/no?

What's interesting is how many smart people get completely fooled by
the sheep's clothing worn by the scope-creep wolf. Everyone knows the
BASIC rules need to be modified but why do so many of these projects
so grossly underestimate the time it will take to get the logic right
in the new environment - and so grossly overestimate the competence of
the people doing this work when they have so little understanding of
how it all worked in the first place? I'm referring to the "let's get
rid of the (cheap) MV people and hire a bunch of (expensive) people
(who haven't worked for years with the app) to do the re-write. One
solution to these disasters (I concede, from my comfortable arm chair
looking back with 20-20 to critique managers who I don't know) is to
ensure that there are people on-hand who understand the logic of the
existing application, and ensure that these people have the power to
veto/defer changes to that logic until the project is complete.

I'm working on a big project with a client right now where it would be
easy to try to make the software do more, as long as we're in there
doing a lot of other stuff. I don't think this one will creep but I'd
certainly recognize the signse and jump on it before it happens. LOL
- I'll let you know in a couple months how that theory works.


I think my whole point was that conversion is not as easy as it might
appear at first-glance, may not make the most sense from a duration
and/or cost perspective, and should really be thought through before
diving in - for the reasons you've stated as well as those I have.

Yup, and I'm sorry I've been so verbose and potentially argumentative
in my agreement with you. :)

(Gosh I gotta stop doing this) ... again
TG@ blahblahblahNebula-RnD.com

What?! No comment on my "Sybase rules" statement??!

Bummer. :-)

Trisha

Nah, everyone is entitled to their opinion.

Regards,
T

.

Relevant Pages

  • Re: What so special about PostgreSQL and other RDBMS?
    ... That's exactly the link the licence agreement for the database points to when it ... comes to what wecan expect for paying support. ... > "Oracle may provide additional releases or versions of its programs ... If the requirements are volatile I'd do a long term contract detailing what ...
    (comp.lang.php)
  • Re: What so special about PostgreSQL and other RDBMS?
    ... > the porting to another database won't be significantly eased. ... not terribly significant and the abstraction can be kept very light ... >> If they where a credible provider of support and development for this ... >> services, exactly like Oracle does, but without trapping you into a ...
    (comp.lang.php)
  • RE: Repairing / modyfing Exchange
    ... Customer Service and Support for more immediate assistance. ... This service gives you access to Microsoft technical support engineers who ... database by using the old Server's database files, ... >> up with the First Storage Group, so you would like to delete it and then ...
    (microsoft.public.windows.server.sbs)
  • Re: we substitute the monthly war
    ... Hey, go obtain a database! ... Mohammad! ... in support of it. ...
    (sci.crypt)
  • GNUmed 0.9.0 released
    ... support primary provider on patients along with configurable ... log failed gm-dbo database access in database during restricted ... fix "Current Substance Intake" edit area usability glitches ... Database installation / upgrade: ...
    (comp.lang.python.announce)