[REBOL] [DEV] Re: dbms3.r 01
From: rgaither:triad:rr at: 13-Jan-2002 20:52
Hi Romano,
>The advantage of row/col is for export functions. It can be easy converted in
>a CVS db for more complex works or to change direction if you see that db
>becomes too big. But i'm open to every solutions. In my custom db i use nested
>blocks which are not easy converted in a row/column struct.
There are many advantages to a row/col based design. I don't mean to
preclude it but I want to also do nested blocks or complex objects or even
simple name:value pairs.
>> Small and flexible are more important to me than fast.
>
>I think it could be modular: basic functions in the main script, additional
>functions, also the same but more complex, in a second one compatible. About
>velocity, i had problems until i started using hash! for indexes.
Modular is good and having different functions that match the task in
complexity also sounds good. This is why I want to start at the bottom -
the interaction with a binary file. Then, on top of that we could build
functions to manage rows and columns, or objects, or name:value pairs
and so on.
>> I don't mind some complexity as long as the design is built to manage
>> most of it internally.
>
>I think about dimensions. But it is a fixation of mine.
You would be right at home with the Pick/UniVerse database system
then. It is multi-dimensional in nature. I am however just an relational
db guy who wants more options than the traditional ones provide. I also
want it all to be simpler as well. (Can you say dreamer? :-))
Thanks, Rod.
Rod Gaither
Oak Ridge, NC - USA
[rgaither--triad--rr--com]
