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

[REBOL] Re: possible data format ... Re: Re: dbms3.r 01

From: rgaither:triad:rr at: 15-Jan-2002 8:43

Hi Joel, Petr, All,
>> I would like to suggest more complex data format, but then it >> really depends upon what you want to achieve. Let's talk >> 1 db = 1 file only.
In reviewing some design options I am having to rethink the desire for a 1 file solution. With a text db it just doesn't seem the best option.
>> 1 ["Petr" "Krenzelok" [petr--krenzelok--trz--cz] 29] "R" >> 2 ["Someone" "Else" [someone--else--com] 18] "D"
Nice. I didn't think of the status option.
>> Some rules: >> - file would be organised in 1 rec = 1 line, so read/lines could >> be eventually used for in-memory mappings ...
This would be nice but I'm not sure it is reasonable for records with a large text block. One of the things I'd like to avoid is imposing limits on record size so something like a webpage could be a record if desired.
>> - new records would be write/appended to the end
Yes, this seems best in this illustration.
>> - record is provided with the status field - important one - >> by default deletion of record doesn't physically delete it from >> the file ...
Sounds good also.
>This certainly fits the KISS mandate. > >Let me mention one slight variation that I've used: > >- new AND UPDATED AND DELETED records are appended to the end of > the file
This is something I have considered as well. Another option would be to have a transaction file or files that either contain whole record changes or just "individual operations". This audit/log could then be applied via a utility to update the main data file when desired. Updating the main file would improve the read operations and bring the db back into an easy to view form.
>which has two consequences, > >1) assuming that write/append is significantly faster than reading > and rewriting the entire file, it minimizes the time for any > revisions, and > >2) obtaining (the current state of) a record requires either > sweeping the entire file or reading backward for the last > occurrence of the record'd unique ID.
All of these issues show the trade offs in the different operations you need to do on the database. Read and search performance versus update and write operations and so on. They conflict quite a bit with the organization I would pick to keep the data in a single file with visually "nice" organization. :-( I will throw out a summary of format options I worked up last night in another post. Thanks, Rod. Rod Gaither Oak Ridge, NC - USA [rgaither--triad--rr--com]