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

[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]