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