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