Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: [DEV] Re: dbms3.r 01

From: greggirwin:mindspring at: 14-Jan-2002 13:13

Rod, Romano, Gabriele, et al (This got longer than I intended, just so you know :) I can see the value in pure RDB systems, though I've rarely used them. Here's why. I'm a big believer in ADTs (Abstract Data Types) and the impedance mismatch between Types/Objects/Structs and RDBs is something I try to avoid at all costs. Yes, I have relationships in my data but most of them are either 1-to-1 or 1-to-a-few type relationships. The 1-to-many (which I call 1-to-infinite) case has been much less prevalent for me. In most of those cases, we had an ADT/object which acted as a kind of "relationship manager". A pure RDB model (I know I'm talking in absolutes here) doesn't allow for arrays (multi-valued values, which I call a 1-to-a-few relationship), which is far more common than the 1-to-infinite relationship, at least in my experience. I want to do as little work as possible, at the application level, to store and retrieve my data. I love the idea of a transparent persistent object system, with the ability to define relationships not implied by an object hierarchy, though most OODBMS I've looked at are far from transparent because they try to be all things to all people. A few years ago, I saw what I thought was a very well designed ORDBMS (orbject-relational) product. It was called Cascade/DB, from Microquill. Another company bought the product and it vanished from sight (and Microquill couldn't name the company who bought it, as part of the deal). It allowed for nested structures, nested tables, object references, and records were, IIRC, variable length blocks of data separated by newlines, so you could pull up the data in an editor without it being complete gibberish. I think editing it manually would have been disastrous, but you could at least see it. I don't know that the row/column format, as a native "mode", buys you anything. If you want to import/export data with other systems, I've always found it easiest to have specific tools for those specific systems. As soon as you get into nested structures, the model becomes burdensome when you try to generalize it. Again, in my experience, real-time interaction with other systems was rarely required. We did most data transfers in batch, polled, or manual import/export fashion. So, for me, I want a simple system that is tightly focused on storing and retrieving REBOL data (probably simple blocks, blocks of name/value pairs, and objects). It should handle up to maybe 50,000 records, though most cases will be far less I imagine. The little things I've done so far have actually worked well using native storage, but the scalability, robustness, and multi-user aspect are something I'm concerned about for more critical uses. --Gregg