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: 14-Jan-2002 12:38

Hi Romano,
>> 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. > >Now i realize that my Rebol databases are made of nested blocks of variable >length. It is not clear to me how to convert them in a row/column scheme. Any >ideas?
Yes, depending on what type of information you have "nested" the most likely option is to treat each nested block or set of blocks as a new table joined with the parent. The hardest part is if data from what would be the same related table appears multiple times, in different nesting locations. For example Addresses nested below individual Person data. Person 1 Home Address Work Address Person 2 Home Address Work Address It can be tough to know that the two different sets of address records are all part of the address table, just joined to different person records.
>> 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. > >Now i understand your point of view. Are you sure it can be done without any >data structure representation?
It certainly can't go very far before some amount of structure information must be imposed. Still, that is the second step and will vary with what is being represented. It is an important distinction even assuming you are building a RDBMS. For example storing index data as a B-Tree structure, or a Hash table, versus storing the row and column data. Each of the above still need to be converted into binary form and managed in variable sizes while reading and writing to the database.
>> 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? :-)) > >Dreams are free. :-)
That is a really good thing for my finances! :-) Thanks, Rod. Rod Gaither Oak Ridge, NC - USA [rgaither--triad--rr--com]