[REBOL] Re: [DEV] Re: dbms3.r 01
From: robert:muench:robertmuench at: 15-Jan-2002 11:19
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
> Gregg Irwin
> Sent: Monday, January 14, 2002 9:13 PM
> To: [rebol-list--rebol--com]
> Subject: [REBOL] Re: [DEV] Re: dbms3.r 01
Hi, just some comments from my POV. IMO a tiny, simple to use persistence system
for Rebol is a very good thing and I could use it in almost all everyday
situations. Up to now, several ways-to-do-it exist and it would help me a lot if
a best-practice shows up.
My requirements would be:
- Simple file format, so I can use other scripts to work on them and do some
analyze things, without having to use the database-driver.
- Simple multiple-user support. Exclusive object-locking would be good.
- Some form of simplest transaction handling. Just to be sure not to get into a
instable datastructure state.
- Close relationship to Rebol's datastructure block! and object!
> 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, ...
And yes, that's what I like to.
> 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.
I know this one. Unfortunately I never got a version to test it and didn't had a
chance to understand the concept better.
> 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).
IMO is could have been MS... as these features poped-up in SQL server, IIRC.
> 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.
Yep, same for me! And here is a suggestion: Why do we want to implement it in
Rebol at all? How about a real simple data-storage system that can be used
through ports from Rebol, that knows about Rebol's datatypes, etc.?
IMO we should write a portable rebol-focused-simple-data-storage-system that can
be used through ports. All the little things you have requested are much easier
to write in C/C++, or something else and get it connected to Rebol. I want to
use Rebol for GUI and process design but not for the requested data-storage.
With this approach, I would go for a non-relational-model. More a graph based
one, that supports lists in nodes etc. Like Cascade allowed it. Do some of you
know Xandadu (http://www.xanadu.net)? It has a concept of a multi-dimension
data-storage, maybe there are some ideas we can use. I really would be
interested in developing such a system, because I need one for my projects too
;-)).
--
Robert M. Münch
IT & Management Freelancer
Mobile: +49 (0)177 2452 802
Fax : +49 (0)721 8408 9112
Web : http://www.robertmuench.de
