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: 16-Jan-2002 8:53

Hi Pekr, Gregg,
>- status markers could be used even for things as locking .... > a) now I am not sure if locking should happen on index level (dangerous if someone >will not use any index), or in database itself ... > b) if we have no db server and our app fails, record would stay locked forever, so we >would have to complicate things with some time-stamps or so ...
I don't think we are ready yet to worry about locking. I have not forgotten it but want to see the first round of file format and function designs before looking at it seriously. Just like I'm not sure what and how to store the table schema information yet but know it needs to be considered.
>- I don't understand how you want to use file appends to manage changes to records. >What rec-number will be used for changed record? It should be the same one. If so, then >we need to introduce versioning (we use such aproach in one of our tables, although for >different purpose)
Yes, it should use the same row-id. My rough cut at the table file has outer blocks for some grouping. This makes for simple organization and basic versioning just by group and position in the file.
>- record-numbers - I hope it is clear enough, that 'pack-ing the database will reassign >record numbers to remove holes caused by record deletion ...
I was not clear on this and am not sure I agree. It will take some more consideration working through some options to be sure but I am leaning towards the row-id being an integer sequence value by table that stays with the record for life. If we make it match the position in the table and change with the pack operation then we must change all the references to that value. It requires some more thought as it seems to me I am mixing some internal position usage and primary key roles in what I am doing so far. Perhaps it should only be an automatic primary key value that goes with the record values not outside the block.
>- variable record size - a block. OK - how will we map it to any rebol >structure/object? I just hope that at least that number of columns are the same thru >all records or I can't imagine it in other way than duplicating column names in each >record, e.g. [name: "pekr" lastname: "krenzelok"], which is not good aproach to follow >imo?
By variable record size I just meant the fields are not fixed length. They are exactly a block of values where each value is whatever size it needs to be. I am not saying variable number of columns. The columns should match a list of column names in order and number. While I like self describing data I agree that I don't want name:value pairs repeating in each record. Here is a sample file structure to consider and review - REBOL [ ; keep header info like table name, namespace, next row-id value ; better in a named value block like columns? ] columns [col-name col-name col-name ...] defaults [ col-name [now/date] ... ] rows [ 1 [col-value col-value col-value ...] "Status" 2 [col-value col-value col-value ...] "Status" 3 [col-value col-value col-value ...] "Status" ] updates [ 2 [col-value col-value col-value ...] "Status" ... ] Please note - this is just a first cut at how a table data file might look. I am putting it out to the list so it can be reviewed and torn apart as needed. :-) My questions on it so far - 1. How best to provide some header information? 2. I like the extra block grouping for flexibility but want some feedback? 3. The defauls block is an example of how the grouping supports extendability 4. The whole row-id/primary-key or both design issue? 5. What status values do we need? 6. Would a action/operation update style vs full records be better?
>So, anyone answers my questions? :-)
Yes, or at least the start of answers for some. :-) Thanks, Rod. Rod Gaither Oak Ridge, NC - USA [rgaither--triad--rr--com]