Re: MV Keys (was: Key attributes with list values)

On Sun, 26 Feb 2006 20:43:46 GMT, "David Cressey"
<dcressey@xxxxxxxxxxx> wrote:

The way Pick (and I presume most of the MV family) represent lists is
inherently ordered. And, whenever I ask Dawn, or any of the other Pickies
who dorp in form time to time whether the order in a list conveys
information or not, the answer is always the same:
"the programmer knows what the data means".

This is a recipe for disaster, even in small-scale systems with a
lifetime of little more than a year or so. And we haven't even begun
to talk about security issues which is one of the main advantages of
using a good RDBMS.

I was involved with the Swiss census in the year 2000 writing stored
procedures for the main database. Although Switzerland is a relatively
small country compared to many, and the data didn't quite reach
teradata dimensions, we had over 100 tables IIRC, some with 10 to 20
million rows constantly being written to and read from by over 100
client PC operators simultaneously. The data went through several
stages, beginning with the data capture (mostly scanning paper forms
with some internet input), validation against prior household data
supplied by the communities, automatic processing (nightly batch jobs)
and manual processing (PC operators) until the final stage was
reached. Conceptually, there were at least four different schemata
involved, one of which was an entirely different database (and RDBMS)
whose data was transferred at night by batch jobs.

The programmers changed several times, even before the project was
finished. But the data is still being mined today, and I would hate to
think what would happen if some newbie application programmer were
allowed to change even one table, index or constraint. When I was
writing code for the batch processes, we had to use an API in order to
perform any DML at all. No one except for the team of DBA's had direct
access to any of the tables except for read-only access. ALL writes
were done through packages. And it was a good thing, believe me (even
though I had to beg for two months for an additional index before the
powers-that-be finally let me have it).

There are performance issues that MV databases probably cannot address
.... but I can't say for myself because I never worked with one. Take
clustering or partitioned tables: what do existing MV products have to
offer here? How do they implement user access rights? Roles?
Transactions? Backup and recovery? These are important issues. The
elegant thing about a good RDBMS is the fact that almost everything
can be implemented through system tables, i.e. RM.

--
Bob Hairgrove
NoSpamPlease@xxxxxxxx
.

Relevant Pages

  • Re: Does Agile Development have to be OO?
    ... communicates with other applications through the database, ... Heavy top-down is more often found in batch jobs rather ... > but there aren't RDBMS there usually). ...
    (comp.object)
  • Re: Good Books on MultiValue Databases
    ... new info there, right?), the database structure when converting from ... an MV environment to an RDBMS actually does require re-architecting. ... Codd wrote his rules specifically ... management system, rather asking the management system to manage ...
    (comp.databases.pick)
  • Re: Good Books on MultiValue Databases
    ... new info there, right?), the database structure when converting from ... an MV environment to an RDBMS actually does require re-architecting. ... Codd wrote his rules specifically ... management system, rather asking the management system to manage ...
    (comp.databases.pick)
  • Re: Closed file system was Re: END-IF
    ... >>> If you can't get to the data without writing a COBOL ... If you need a programmer to use utilities like ... >>>With a RDBMS he can. ... >>>reports from IT if they opted for RDBMS, it was amazing how quickly they ...
    (comp.lang.cobol)
  • Re: Lucid statement of the MV vs RM position?
    ... before database managment systems, much of Pick will be familiar to you. ... Dictionaries are ... mind of the end-users too. ... decoding the data ought to be in the mind of the programmer, ...
    (comp.databases.theory)