[REBOL] Re: possible data format ... Re: Re: dbms3.r 01
From: petr:krenzelok:trz:cz at: 16-Jan-2002 15:14
Rod Gaither wrote:
> 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.
>
OK
> >- 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.
Record numbers should be in no way related to data content. What relations are you talking
about? We relate tables thru some column or set of columns, not some internal database
stored information. Record numbers should serve for index values, where e.g. sorting
order
of name + last-name would store something like:
1 "Petr Krenzelok"
35 "Petr someone"
3 "Olaf xyz"
so that you can choose your index tag, and set filter for e.g. to see only all Petrs
- your
table-grid viewer driver will then fill in your grid directly selecting only record numbers
1 and 35 in above example ...
> 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"
> ...
> ]
>
One thing I don't like so far - why to add changes to table/database itself? I think
that
more correct is one of following:
a) replace record ...
b) if you want to track changes, introduce some logging, but don't complicate database
with
some values and their updates/history .... just imo :-)
> 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?
a) as first block/row in a file
b) separate file, e.g. .def file, specifying index (or more of them), unique ids, field
names = record structure, or other things for maintanance
I prefer b), simply to have clear and containing-records-only data file ...
> 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?
Deleted
, later maybe "locked" etc .... let's start with "deleted" one, or just let's
preserve such field for future usage :-)
> 6. Would a action/operation update style vs full records be better?
? Could you explain this one, please?
Thanks,
-pekr-
