[REBOL] Re: possible data format ... Re: Re: dbms3.r 01
From: rgaither:triad:rr at: 16-Jan-2002 10:40
Hi Pekr,
>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"
I am talking about internal db relationships like the indexes. I was starting
to confuse the row-id with my desire to always have a unique ID value that
is auto-generated as a value for each row of a table - to server as a primary
key. After thinking about it a bit though they have to be two separate things
and I'm not sure everyone will go along with a default ID column in a record
anyway. :-)
>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 ...
I don't know if I want to have to update all the index data every time we pack
the DB. That can be looked at later though when starting to work on how
the functions interact with the files.
>> 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 ...
I don't think you can in the text db. How are you planning on doing this
without having to rewrite the entire file for every change?
>b) if you want to track changes, introduce some logging, but don't complicate database
with
>some values and their updates/history .... just imo :-)
I agree, but I am not - see above. :-)
I am not sure I want the updates in the same file myself. That was a
point Joel brought up where I was thinking of a separate file. I am in
the middle on where the list of changes goes, I just know it has to be
at the end of some file so append can be used.
>> 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 ...
I like (a) for some parts and (b) for the full schema information. The only
reason for (a) is to give included mapping between columns and data
and store real values - not schema - such as the next row-id with the
data.
>> 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 :-)
Ok.
>> 6. Would a action/operation update style vs full records be better?
>
>? Could you explain this one, please?
I have a problem with repeating the entire record in the update section
if the only thing that has changed is the value of one column. By having
a list of operations that could be at the field level or record level there is
finer granularity to the process. This might also be considered a low level
data manipulation language that gets applied to the table data to bring it
in back in sync during packing. It complicates things at the engine level
but should give better performance and more flexibility in activities.
Some examples:
Whole record -
2 ["Rod" "Gaither" [rgaither--triad--rr--com] ...] "U"
Action -
Update 2 first-name "Roderic"
Other examples -
Delete 3
Create ["Gabriele" "Santilli" [g--santilli--tiscalinet--it]] "N"
For transaction support we may need to consider putting these update
lists in there own file so we can manage multiple table changes as a
single transaction.
Thanks, Rod.
Rod Gaither
Oak Ridge, NC - USA
[rgaither--triad--rr--com]
