> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Gregg Irwin > Sent: Monday, January 14, 2002 9:13 PM > To: [EMAIL PROTECTED] > 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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
