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: joel:neely:fedex at: 15-Jan-2002 5:56

Hi, Petr, Gabriele, et al, Petr Krenzelok wrote:
> Hi once again, > > 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. > > 1 ["Petr" "Krenzelok" [petr--krenzelok--trz--cz] 29] "R" > 2 ["Someone" "Else" [someone--else--com] 18] "D" > > Some rules: > - file would be organised in 1 rec = 1 line, so read/lines could > be eventually used for in-memory mappings ... > - new records would be write/appended to the end > - record is provided with the status field - important one - > by default deletion of record doesn't physically delete it from > the file ...
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 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. I've used this in situations where the normal read is, in fact, a query looking for all records (or all records meeting some set of criteria), which means that sweeping the entire file is not a mjor penalty. -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;