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

On Sun, 26 Feb 2006 20:43:46 GMT, "David Cressey" <dcressey_at_verizon.net> 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_at_Home.com