Record Id numbers

[Peter J. Seymour]

I have been working on a genealogical data model and an associated
implementing program for some time. Some people have questioned my
competence, but have failed to provide any specific criticisms. Unlike
some new schemes which rise and then seem to soon die, my scheme
continues to progress, albeit in a somewhat leisurely manner. It has
reached the point where I should release a demo program and I hope to do
this 'before long'.
I have been pondering some issues relating to id numbers and I just want
to share a few points.
- The program currently has no means of defining the allowed range of id
numbers for a file. In my view, it ought to and I intend to include the
facility in any production version. Such a facility would enable proper
multiple file use including multi-file projects. But how useful is this
in practice? Do people care what id numbers they are using?
- I allow the numbers to be any number of digits in principle. There is
a current implementation maximum imposed by using 31 bit integers
internally, but this could be increased to say 63 bit without much
effort. 31 bit integers will not accommodate everyone currently living,
63 bits would accommodate everyone living and everyone who has ever
lived with seemingly infinite room to spare. Is this an issue? Does it
matter?
- I intend to use a default length of 6 digits. This allows a maximum
number of records of 999,999 which would include all types - persons,
addresses, events, evidence etc. For sake of argument with a ratio of
one person per 100 records, this would allow up to around 10,000 people
to be recorded. Is this too few? This is really a matter of what is a
convenient starting width as the program gui would be expected to react
automatically to an increase in the field width caused by an extra digit
coming into use.
- If number ranges are defined per file and data is moved between files,
some records will get renumbered. This means that the allocated id
number cannot be taken as a permanent identifier. Is this a problem?
Does there need to be a "permanent" id field?
How would such a field be populated?
- If multiple files are allowed, would people want to use cross-file
references? (I suppose the answer is 'yes', the question is really
looking for justification of such practice).

Thanks for the interest. Feel free to contact me direct if you don't
want to clutter up the newsgroup.
Peter
further info at: http://www.pjsey.demon.co.uk/genealog/genindex.htm

[Charlie]

On Mon, 30 Aug 2004 10:31:17 +0100, "Peter J. Seymour"
<[email protected]> wrote:

- The program currently has no means of defining the allowed range of id
numbers for a file. In my view, it ought to and I intend to include the
facility in any production version. Such a facility would enable proper
multiple file use including multi-file projects. But how useful is this
in practice? Do people care what id numbers they are using?
- I allow the numbers to be any number of digits in principle. There is
a current implementation maximum imposed by using 31 bit integers
internally, but this could be increased to say 63 bit without much
effort. 31 bit integers will not accommodate everyone currently living,
63 bits would accommodate everyone living and everyone who has ever
lived with seemingly infinite room to spare. Is this an issue? Does it
matter?

I guess it depends on what you;re trying to use the numbers for. For
example, RootsMagic generates a unique ID number for every person you
enter. The number is "completely" unique. So if I share information
back & forth with a relative, say by transferring GEDCOMS, when I
import the GEDCOM, RM can automatically tell which individuals are
true duplicates (from my own file sent eariler to my relative),
because their UID's are the same, and merge those individuals. Makes
sharing data very easy. If my relative used a different program that
didn't maintain the same UID number, the system wouldn't work.

Charlie Hoffpauir
http://freepages.genealogy.rootsweb.com/~charlieh/

[0_Qed]

Peter,

Phew!
Tall Order, you "put" there.

I have been working on a genealogical data model and an associated
implementing program for some time. Some people have questioned my
competence, but have failed to provide any specific criticisms.

Nah ... 'who' am I to 'critique'.

Please excuse the following un_flagged 'snips' ...

I have been pondering some issues relating to id numbers and I just want
to share a few points.

I'd presume that "an" individual's ID_# aughta be inviolate & absolutely
unique.

A( the ? ) basic 'canon' for a robust DB "engine".


Is this too few? This is really a matter of what is a

convenient starting width as the program gui would be expected to react
automatically to an increase in the field width caused by an extra digit
coming into use.

Whoosh!

" .. automatically to an increase in the field width "

implies an on_the_spot, 'near' total 're_org' of the entire DB
depending upon
the Schema/Linkage design .

- If multiple files are allowed, would people want to use cross-file
references? (I suppose the answer is 'yes', the question is really
looking for justification of such practice).

" .. multiple files are allowed "

I assume you intend that the "ID's" ( & records ),
of =foreign= DBs,
be 'allowed entry into another( your ?? ) "DB" ...
yes???

The 'task' then becomes that of 100% 'in_coming' filtering
to identify the =true= dupes ...
doable , but ...
whoosh!

Thanks for the interest. Feel free to contact me direct if you don't
want to clutter up the newsgroup.
Peter
further info at: http://www.pjsey.demon.co.uk/genealog/genindex.htm

Can contact you , off NG, if you wish.
Vastly Tooo much verbage to accomplish 'in' a NG ...
puts a lotta folks to 'sleep'.
Mite be able to 'assist' with various 'points' in your design & code.

Admirable 'task' ... not all that easily done well.

Qed.

[Peter J. Seymour]

This "sharing" scenario is the only one in which I can see unique
permanent ids working. It depends on data being originally copied from a
single source file and then later merged back again. It also depends on
unrelated data not happening to have the same ids. However, in a
limited, controlled environment it obviously works. I don't see any
feasible way of unrelated programs generating the same permanent id for
a person - there are too many imponderables.
Peter

Charlie wrote:

On Mon, 30 Aug 2004 10:31:17 +0100, "Peter J. Seymour"
[email protected]> wrote:

- The program currently has no means of defining the allowed range of id
numbers for a file. In my view, it ought to and I intend to include the
facility in any production version. Such a facility would enable proper
multiple file use including multi-file projects. But how useful is this
in practice? Do people care what id numbers they are using?
- I allow the numbers to be any number of digits in principle. There is
a current implementation maximum imposed by using 31 bit integers
internally, but this could be increased to say 63 bit without much
effort. 31 bit integers will not accommodate everyone currently living,
63 bits would accommodate everyone living and everyone who has ever
lived with seemingly infinite room to spare. Is this an issue? Does it
matter?

I guess it depends on what you;re trying to use the numbers for. For
example, RootsMagic generates a unique ID number for every person you
enter. The number is "completely" unique. So if I share information
back & forth with a relative, say by transferring GEDCOMS, when I
import the GEDCOM, RM can automatically tell which individuals are
true duplicates (from my own file sent eariler to my relative),
because their UID's are the same, and merge those individuals. Makes
sharing data very easy. If my relative used a different program that
didn't maintain the same UID number, the system wouldn't work.

Charlie Hoffpauir
http://freepages.genealogy.rootsweb.com/~charlieh/

[Peter J. Seymour]

I see the "display size" as determined by the absolute value of the
number as distinct from the allowed maximum size. So a bump up from say
6 to 7 digits in the display as the ids went from 999999 to 1000000
would have no impact on the stored data which might for instance be in
31 bit integer fields (which could accommodate a display width of 10
digits). An on-the-fly resizing of gui objects within the displayed
window is no big deal for environments such as Java.
Peter.

0_Qed wrote:

Peter,

Phew!
Tall Order, you "put" there.

I have been working on a genealogical data model and an associated
implementing program for some time. Some people have questioned my
competence, but have failed to provide any specific criticisms.

Nah ... 'who' am I to 'critique'.

Please excuse the following un_flagged 'snips' ...

I have been pondering some issues relating to id numbers and I just want
to share a few points.

I'd presume that "an" individual's ID_# aughta be inviolate & absolutely
unique.

A( the ? ) basic 'canon' for a robust DB "engine".

Is this too few? This is really a matter of what is a
convenient starting width as the program gui would be expected to react
automatically to an increase in the field width caused by an extra digit
coming into use.

Whoosh!

" .. automatically to an increase in the field width "

implies an on_the_spot, 'near' total 're_org' of the entire DB
depending upon
the Schema/Linkage design .

- If multiple files are allowed, would people want to use cross-file
references? (I suppose the answer is 'yes', the question is really
looking for justification of such practice).

" .. multiple files are allowed "

I assume you intend that the "ID's" ( & records ),
of =foreign= DBs,
be 'allowed entry into another( your ?? ) "DB" ...
yes???

The 'task' then becomes that of 100% 'in_coming' filtering
to identify the =true= dupes ...
doable , but ...
whoosh!

Thanks for the interest. Feel free to contact me direct if you don't
want to clutter up the newsgroup.
Peter
further info at: http://www.pjsey.demon.co.uk/genealog/genindex.htm


Can contact you , off NG, if you wish.
Vastly Tooo much verbage to accomplish 'in' a NG ...
puts a lotta folks to 'sleep'.
Mite be able to 'assist' with various 'points' in your design & code.

Admirable 'task' ... not all that easily done well.

Qed.

[Charlie]

On Tue, 31 Aug 2004 17:19:11 +0100, "Peter J. Seymour"
<[email protected]> wrote:

This "sharing" scenario is the only one in which I can see unique
permanent ids working. It depends on data being originally copied from a
single source file and then later merged back again. It also depends on
unrelated data not happening to have the same ids. However, in a
limited, controlled environment it obviously works. I don't see any
feasible way of unrelated programs generating the same permanent id for
a person - there are too many imponderables.
Peter

You are exactly correct. Each Unique ID number is truly unique. As you
say, this is the only case for long ID numbers.... but isn't this
exactly what you asked for.... any need for longer than your intended
6 digits?

Charlie Hoffpauir
http://freepages.genealogy.rootsweb.com/~charlieh/

[singhals]

Peter J. Seymour wrote:

I see the "display size" as determined by the absolute value of the
number as distinct from the allowed maximum size. So a bump up from say
6 to 7 digits in the display as the ids went from 999999 to 1000000
would have no impact on the stored data which might for instance be in
31 bit integer fields (which could accommodate a display width of 10
digits). An on-the-fly resizing of gui objects within the displayed
window is no big deal for environments such as Java.

Frimmin at Jam-Jam. Pragmatically, why would one want a number one
couldn't see, would never remember, and hence couldn't use for anything?
Sounds like a bald man hoarding hairpins to me.

Cheryl

[Charlie]

On Tue, 31 Aug 2004 13:29:19 -0400, singhals <[email protected]>
wrote:

Peter J. Seymour wrote:

I see the "display size" as determined by the absolute value of the
number as distinct from the allowed maximum size. So a bump up from say
6 to 7 digits in the display as the ids went from 999999 to 1000000
would have no impact on the stored data which might for instance be in
31 bit integer fields (which could accommodate a display width of 10
digits). An on-the-fly resizing of gui objects within the displayed
window is no big deal for environments such as Java.

Frimmin at Jam-Jam. Pragmatically, why would one want a number one
couldn't see, would never remember, and hence couldn't use for anything?
Sounds like a bald man hoarding hairpins to me.

Cheryl

Cheryl,

In some cases (rare probably) people find them extremely useful. See
my post to Peter of the other day on the same subject.

Charlie Hoffpauir
http://freepages.genealogy.rootsweb.com/~charlieh/

[0_Qed]

singhals wrote:

Frimmin at Jam-Jam. Pragmatically, why would one want a number one
couldn't see, would never remember, and hence couldn't use for anything?

As "PJS" originally wrote ...
"
I intend to use a default length of 6 digits. This allows a maximum
number of records of 999,999 which would include all types - persons,
addresses, events, evidence etc. For sake of argument with a ratio of
one person per 100 records, this would allow up to around 10,000 people
to be recorded. Is this too few?
/"
....
which leads me to suspect hes contemplating some undefined ,
internal DB engine, record management scheme using this 6_dig_number.

SOoooo,
in most all circumstances , you're "correct" ...
the 'user' doesnt/shouldnt care about it ,
=but=
the DB engine mite.

For my 'part',
I'll wait to see what 'use' PJS makes of this
[Record ID] in all 'record types' ...
=over and above=
what data-elements are chosen as 'keys' for these same 'record types'.

Maybe hes' developed a new 'gimmick' in the DB engine design world.

Sounds like a bald man hoarding hairpins to me.

?Do? I 'smell' chauvinist bacon a_frying ???
Why deny a bald "male" his fondest wish ???
<VBG> <kidding>


Qed.

[0_Qed]

Charlie wrote:

Cheryl,
In some cases (rare probably) people find them extremely useful. See
my post to Peter of the other day on the same subject.

Charlie,

Mite I respectfully suggest you re_read PJS's original post ...
reading between his 'lines' ... I suspect =his= 6_dig Record ID
isnt a "people" useable number at all, at all.

Maybe PJS can clear this up for us.

I'd =quickly= add that a " unique individual ID " , as found in most
genealogy DB packages , =is= a people useable "#" ...
=and= ,
vital to the DB engine itself.


Qed.

[Charlie]

On Tue, 31 Aug 2004 19:43:09 -0400, 0_Qed <[email protected]>
wrote:

Charlie wrote:
Cheryl,
In some cases (rare probably) people find them extremely useful. See
my post to Peter of the other day on the same subject.

Charlie,

Mite I respectfully suggest you re_read PJS's original post ...
reading between his 'lines' ... I suspect =his= 6_dig Record ID
isnt a "people" useable number at all, at all.
snip

OK. "people find them extremely useful" does seem to imply that people
are actually "using" the numbers. However, in the program I was
referring to, you (people) don't actually ever see the UID number....
the program uses it internally, and one of the functions it uses them
for, is found extremely useful by people.


Charlie Hoffpauir
http://freepages.genealogy.rootsweb.com/~charlieh/

[Rick Merrill]

Peter J. Seymour wrote:

I have been working on a genealogical data model and ...
pondering some issues relating to id numbers ...

Many programs import GEDCOM and permit retaining the ID numbers from
that GEDCOM. This is extremely useful, especially for correcting
errors in the new or old data base. RootsMagic (and Family Origins)
and other programs call it the "rec no." or record number.

Note that the record numbers are not necessrialy a complete set:
some numbers may have been deleted!

I feel that retaining record numbers is more vital to genealogical
use than the "range" of numbers allowed. (6 digits is enough)

Do people care what id numbers they are using?

Yes, for goodness sakes, many people start out using record numbers
estabilished by old genealogical texts.

... 31 bit integers will not accommodate everyone currently living

Bummer

- RM

[singhals]

Charlie wrote:

On Tue, 31 Aug 2004 19:43:09 -0400, 0_Qed <[email protected]
wrote:


Charlie wrote:

Cheryl,
In some cases (rare probably) people find them extremely useful. See
my post to Peter of the other day on the same subject.

Charlie,

Mite I respectfully suggest you re_read PJS's original post ...
reading between his 'lines' ... I suspect =his= 6_dig Record ID
isnt a "people" useable number at all, at all.

snip
OK. "people find them extremely useful" does seem to imply that people
are actually "using" the numbers. However, in the program I was
referring to, you (people) don't actually ever see the UID number....
the program uses it internally, and one of the functions it uses them
for, is found extremely useful by people.


Charlie Hoffpauir
http://freepages.genealogy.rootsweb.com/~charlieh/

If the discussion is over those wretched UIDs in PAF, they aren't
people-usable (see note), they're machine usable, but that requires
placing reliance on the machine, a thing most of us are reluctant to do
(see note 2). And if PAF or any other program has, as is claimed, an
"unlimited" db size, then the potential number of UIDs needed is
likewise unlimited, so the number of necessary digits is unknowable.

Cheryl

NOTE: technically, you CAN GED 'em out and look at them and so "use"
them in any way you see fit, including copying them into the NOTES or
SOURCES.

NOTE 2: do you pick AUTO MERGE or MANUAL MERGE? (g)

[singhals]

0_Qed wrote:

singhals wrote:

Frimmin at Jam-Jam. Pragmatically, why would one want a number one
couldn't see, would never remember, and hence couldn't use for anything?



As "PJS" originally wrote ...
"
I intend to use a default length of 6 digits. This allows a maximum
number of records of 999,999 which would include all types - persons,
addresses, events, evidence etc. For sake of argument with a ratio of
one person per 100 records, this would allow up to around 10,000 people
to be recorded. Is this too few?
/"
...
which leads me to suspect hes contemplating some undefined ,
internal DB engine, record management scheme using this 6_dig_number.

SOoooo,
in most all circumstances , you're "correct" ...
the 'user' doesnt/shouldnt care about it ,
=but=
the DB engine mite.

For my 'part',
I'll wait to see what 'use' PJS makes of this
[Record ID] in all 'record types' ...
=over and above=
what data-elements are chosen as 'keys' for these same 'record types'.

Maybe hes' developed a new 'gimmick' in the DB engine design world.

See note to Charlie H.

Sounds like a bald man hoarding hairpins to me.


?Do? I 'smell' chauvinist bacon a_frying ???

No. There were others I could have used, Twiggy pricing support bras?


Cheryl

[0_Qed]

singhals wrote:

.....................

If the discussion is over those wretched UIDs in PAF, they aren't
people-usable (see note), they're machine usable, but that requires
placing reliance on the machine, a thing most of us are reluctant to do
(see note 2).

I'm inclined to think that PJS's "record_numbers" are =strictly=
an internal, DB_Engine kinda 'beastie' ...

PJS( the 'OP' ) aughta clear that up for us .

.....................

And if PAF or any other program has, as is claimed, an
"unlimited" db size, then the potential number of UIDs needed is
likewise unlimited, so the number of necessary digits is unknowable.

<VBG>
[ "unlimited" db size } is a 'concept', not a purchaseable reality,
kinda like " content addressable hdwr_memory ".



.....................

NOTE: technically, you CAN GED 'em out and look at them and so "use"
them in any way you see fit, including copying them into the NOTES or
SOURCES.

.....................

NOTE 2: do you pick AUTO MERGE or MANUAL MERGE? (g)

As a =general= rule, truely, uniquely "ID'd" DB records,
from a foriegn DB aughta be screened for duplication before permitting a
merge ...
ie: for 'dupes', of instances. in the recieving DB ...
by some "one" means or another ... via human, or programatically.

That 'said' ...
I'd suggest a) dupe screening, followed by b) Manual "y/n" merge.

Qed.

[0_Qed]

singhals wrote:

See note to Charlie H.

Done.

No. There were others I could have used, Twiggy pricing support bras?

Touche' .


Qed.

[singhals]

0_Qed wrote:

singhals wrote:

....................

If the discussion is over those wretched UIDs in PAF, they aren't
people-usable (see note), they're machine usable, but that requires
placing reliance on the machine, a thing most of us are reluctant to do
(see note 2).


I'm inclined to think that PJS's "record_numbers" are =strictly=
an internal, DB_Engine kinda 'beastie' ...

PJS( the 'OP' ) aughta clear that up for us .

....................

And if PAF or any other program has, as is claimed, an
"unlimited" db size, then the potential number of UIDs needed is
likewise unlimited, so the number of necessary digits is unknowable.


VBG
[ "unlimited" db size } is a 'concept', not a purchaseable reality,
kinda like " content addressable hdwr_memory ".



....................

NOTE: technically, you CAN GED 'em out and look at them and so "use"
them in any way you see fit, including copying them into the NOTES or
SOURCES.


....................

NOTE 2: do you pick AUTO MERGE or MANUAL MERGE? (g)


As a =general= rule, truely, uniquely "ID'd" DB records,
from a foriegn DB aughta be screened for duplication before permitting a
merge ...
ie: for 'dupes', of instances. in the recieving DB ...
by some "one" means or another ... via human, or programatically.

That 'said' ...
I'd suggest a) dupe screening, followed by b) Manual "y/n" merge.

Qed.

Since you used a word somewhere in there that implies to me you might
have the answer to this: we're trying to set up a default path on a win
2Kpro box. It keeps telling us it is "not a valid relative path".
Could someone give me an example of what it might think IS a valid
relative path ?? (Yes, we're logged on as admin)

[0_Qed]

singhals wrote:
....snip...

Since you used a word somewhere in there that implies to me you might
have the answer to this: we're trying to set up a default path on a win
2Kpro box. It keeps telling us it is "not a valid relative path".

Whats the 'app' ... Word ???

*If* =in= 'word' ...
Are you attempting a 'hyper_link', or a relative path, to "some" file
???

Could someone give me an example of what it might think IS a valid
relative path ?? (Yes, we're logged on as admin)

I'm 'guessing(swag)', here ...
In "XP" ==> 1st check "this" ==>
Tools/Options/General/Web Options/Files ...
try the checkbox to update file paths on save is turned OFF, or ON.
Makes a difference.

Continuing "on" ...
I'm assuming "our" defs of [relative] equate ...
.. the "path" twixt two(2) files ...
& I =further= assume your two paths look like this

x:/d1/d2/.../file1
y:/d3/d4/.../file2

If x: is not the same as y:,
then the relative_path(rp) from [file1] to [file2]
is just the full path of file2.
....
Otherwise, (not=)
I think I'd use the 'above' full_path also,
altho , "it" mite not =strictly= be defined as a true 'rp'.

There is a 'method' to programatically develop such a 'path',
from the two(2) given "paths" ...
a bit too 'geeky_baffle_gabish' , tho.
Kinda like climbing 'up' the ltrd_drv tree, from file1,
change the ltrd_drv,
climb 'down' to the file2 ...
"Said" developed-path containing all the up/down nagrivational elements
.... if "that" makes sense.

M$ OSs have no embedded 'gimmick' to handle 'up/down' paths as mite a
Unix OS.

Almost 'smacks' of an attempt to use "Word" as a DB_engine 'tool' ...
record linkage & navigation.

Nah ... use Access. < ducks head >

Qed.

[singhals]

0_Qed wrote:

singhals wrote:
...snip...

Since you used a word somewhere in there that implies to me you might
have the answer to this: we're trying to set up a default path on a win
2Kpro box. It keeps telling us it is "not a valid relative path".


Whats the 'app' ... Word ???

*If* =in= 'word' ...
Are you attempting a 'hyper_link', or a relative path, to "some" file
???


Could someone give me an example of what it might think IS a valid
relative path ?? (Yes, we're logged on as admin)


I'm 'guessing(swag)', here ...
In "XP" ==> 1st check "this" ==
Tools/Options/General/Web Options/Files ...
try the checkbox to update file paths on save is turned OFF, or ON.
Makes a difference.

Continuing "on" ...
I'm assuming "our" defs of [relative] equate ...
. the "path" twixt two(2) files ...
& I =further= assume your two paths look like this

x:/d1/d2/.../file1
y:/d3/d4/.../file2

If x: is not the same as y:,
then the relative_path(rp) from [file1] to [file2]
is just the full path of file2.
...
Otherwise, (not=)
I think I'd use the 'above' full_path also,
altho , "it" mite not =strictly= be defined as a true 'rp'.

There is a 'method' to programatically develop such a 'path',
from the two(2) given "paths" ...
a bit too 'geeky_baffle_gabish' , tho.
Kinda like climbing 'up' the ltrd_drv tree, from file1,
change the ltrd_drv,
climb 'down' to the file2 ...
"Said" developed-path containing all the up/down nagrivational elements
... if "that" makes sense.

M$ OSs have no embedded 'gimmick' to handle 'up/down' paths as mite a
Unix OS.

Almost 'smacks' of an attempt to use "Word" as a DB_engine 'tool' ...
record linkage & navigation.

Nah ... use Access. < ducks head

Qed.

Not XP, remember: 2K professional.

What we're trying to do is the old DOS .bat file routine, where I press
a POWER switch, the machine boots, logs me in as GUEST, and opens a
graphics program.

Speek-geek, I know a *lot* of programmers and several sys-Analysts who
read core dumps. (g)

Cheryl

[Peter J. Seymour]

Probably in my scheme what will result is that any record may have a
list attached to it that consists of whatever 'permanent' ids the user
may wish to apply (along with a 'type' for each item). It is easy to
incorporate in the data structure. Not so easy in the already cluttered
user interface. I will have to get a move on to get it in the demo, at
the risk of yet more delay.
Regards
Peter

[0_Qed]

singhals wrote:

Not XP, remember: 2K professional.

Oops! My 'Senior Moment'.

What we're trying to do is the old DOS .bat file routine, where I press
a POWER switch, the machine boots, logs me in as GUEST, and opens a
graphics program.

Sounds like 'that' aughta be a rather simple 'Start Up' task, no ?

I dont quite fathom how/where the "relative path(rp)" thingie fits ???
Most probably I dont understand your definition of 'rp'.

Speek-geek, I know a *lot* of programmers and several sys-Analysts who
read core dumps. (g)

"Those" types, are =generally=, "types" to avoid.

"They" probably have difficulty 'communicating' with self,
let alone you.
<VBG>

Luckily, my 'shock treatments' cured me of "that" ... I ?think?.
<twitch><twitch>

Qed.

[0_Qed]

Hello "PJS" ,

.................

Probably in my scheme what will result is that any record may have a
list attached to it that consists of whatever 'permanent' ids the user
may wish to apply (along with a 'type' for each item).

So 'far' , I follow you.


.................

It is easy to incorporate in the data structure[it].

I can "agree", insofar as you've 'qualified' [it].

I must quickly =add=,
[it's] =use= mite seem a "bear" for the DB engine.

I am 'almost' coming to the conclusion you're intent on
building your very own "DB" engine. y/n ??


.................

Not so easy in the already cluttered user interface.

Worry `bout the poor 'DB' engine code 1st ...
most "UIs"( data_entry/reporting ) sort themselves out.

Consider too, along the "way" ...
the compromises to be made twixt
.. easy, facile, 'correct' original_data_entry into the "structure",
, ^..... " .........^ reporting from ^.. " .. ^ .


.................
I assume you're scratch building ;
a). the data_entry modules ,
b), the DB engine 'stuff',
c). the reporting modules,
d). the "UI" wrapper for all_above.



.................

I will have to get a move on to get it in the demo, at
the risk of yet more delay.

Nah ,
theres' =always= time to re_DO a 2nd. 3rd, ad_nauseum, "time".
< joking >

Me?
=Seriously=,
I'd think about using a =real= DB engine 'app',
and its' embedded language, and "relative_file" handling 'stuff'.
Got 'Access' ??? Open Office(freebie) ???

'Above' takes the =pain= out of a/b/c) ... eases d).


Qed.

PS- Hope I havent "rained" on your 'parade'.
.. Oh Well.
.. Into each 'life', a little ....

[Peter J. Seymour]

Yes what there is is custom built apart from the Java contribution, but
there is not much of a 'DB engine' involved in this. An aspect of the
project is to explore what can be done with simple (i.e. non-complex)
programming. A current aim is to keep below the threshold where there is
a major proliferation in complexity. An interesting challenge is to
provide adequate reporting. Judge the result for youself once a demo
becomes available.
Using a proper database system is a 'future consideration' as a way of
dealing with 'large' files.
Actually, the 'permanent id list' has also become a future consideration
(too much work to fit in quickly). I will settle for a hidden permanent
id for the time being.
BTW 'rain' is not a problem. I know what I am doing will work. It is
using proven techniques.
Peter

0_Qed wrote:

Hello "PJS" ,

................
Probably in my scheme what will result is that any record may have a
list attached to it that consists of whatever 'permanent' ids the user
may wish to apply (along with a 'type' for each item).


So 'far' , I follow you.

................
It is easy to incorporate in the data structure[it].

I can "agree", insofar as you've 'qualified' [it].

I must quickly =add=,
[it's] =use= mite seem a "bear" for the DB engine.

I am 'almost' coming to the conclusion you're intent on
building your very own "DB" engine. y/n ??

................
Not so easy in the already cluttered user interface.


Worry `bout the poor 'DB' engine code 1st ...
most "UIs"( data_entry/reporting ) sort themselves out.

Consider too, along the "way" ...
the compromises to be made twixt
. easy, facile, 'correct' original_data_entry into the "structure",
, ^..... " .........^ reporting from ^.. " .. ^ .

................
I assume you're scratch building ;
a). the data_entry modules ,
b), the DB engine 'stuff',
c). the reporting modules,
d). the "UI" wrapper for all_above.

................
I will have to get a move on to get it in the demo, at
the risk of yet more delay.

Nah ,
theres' =always= time to re_DO a 2nd. 3rd, ad_nauseum, "time".
joking

Me?
=Seriously=,
I'd think about using a =real= DB engine 'app',
and its' embedded language, and "relative_file" handling 'stuff'.
Got 'Access' ??? Open Office(freebie) ???

'Above' takes the =pain= out of a/b/c) ... eases d).

Qed.

PS- Hope I havent "rained" on your 'parade'.
. Oh Well.
. Into each 'life', a little ....

[D. Stussy]

On Mon, 30 Aug 2004, Peter J. Seymour wrote:

I have been working on a genealogical data model and an associated
implementing program for some time. Some people have questioned my
competence, but have failed to provide any specific criticisms. Unlike
some new schemes which rise and then seem to soon die, my scheme
continues to progress, albeit in a somewhat leisurely manner. It has
reached the point where I should release a demo program and I hope to do
this 'before long'.
I have been pondering some issues relating to id numbers and I just want
to share a few points.
- The program currently has no means of defining the allowed range of id
numbers for a file. In my view, it ought to and I intend to include the
facility in any production version. Such a facility would enable proper
multiple file use including multi-file projects. But how useful is this
in practice? Do people care what id numbers they are using?
- I allow the numbers to be any number of digits in principle. There is
a current implementation maximum imposed by using 31 bit integers
internally, but this could be increased to say 63 bit without much
effort. 31 bit integers will not accommodate everyone currently living,
63 bits would accommodate everyone living and everyone who has ever
lived with seemingly infinite room to spare. Is this an issue? Does it
matter?
- I intend to use a default length of 6 digits. This allows a maximum
number of records of 999,999 which would include all types - persons,
addresses, events, evidence etc. For sake of argument with a ratio of
one person per 100 records, this would allow up to around 10,000 people
to be recorded. Is this too few? This is really a matter of what is a
convenient starting width as the program gui would be expected to react
automatically to an increase in the field width caused by an extra digit
coming into use.
- If number ranges are defined per file and data is moved between files,
some records will get renumbered. This means that the allocated id
number cannot be taken as a permanent identifier. Is this a problem?
Does there need to be a "permanent" id field?
How would such a field be populated?
- If multiple files are allowed, would people want to use cross-file
references? (I suppose the answer is 'yes', the question is really
looking for justification of such practice).

Thanks for the interest. Feel free to contact me direct if you don't
want to clutter up the newsgroup.
Peter
further info at: http://www.pjsey.demon.co.uk/genealog/genindex.htm

There should be no limit on the format of an "ID" or reference number. It
should be a free-flowing string field.

I have seen sources where people are numbered sequentially. I have seen
sources where people have a digit for each generation they are away from the
family progenitor (and that digit's value is their birth order - i.e. 3 = born
third). I have seen sources which use LETTERS instead of digits for the birth
order.

In my own research, I use "<marker>:<ref-code>" since a person may have more
than one reference number due to different sources (especially when traced from
different ancestors); the "marker" part being an abbreviation for the source,
and the "ref-code" being the reference code from that source. Technically,
LDS-Church assigned AFNs and government assigned numbers (e.g. SSN for the
U.S.) can also be reference ids, and with the AFNs, there can be more than one
(although the church says differently, I have found some people that have up to
4 of them).

As far as INTERNAL numbers go for the operation of the program, they should
probably be (32-bit unsigned "integers") whole numbers starting at 1 for the
first person (reserving zero to mean NULL when used as a "person pointer") and
stop at the last person entered, however many that is. With 32 bits, one can
reach 4 billion, and I seriously doubt that one will ever get a single database
with that many people linked in. (I don't see 64-bit numbers as necessary.)

[D. Stussy]

On Tue, 31 Aug 2004, Peter J. Seymour wrote:

This "sharing" scenario is the only one in which I can see unique
permanent ids working. It depends on data being originally copied from a
single source file and then later merged back again. It also depends on
unrelated data not happening to have the same ids. However, in a
limited, controlled environment it obviously works. I don't see any
feasible way of unrelated programs generating the same permanent id for
a person - there are too many imponderables.

There are certain things that ARE supposed to be "keys" in nature: AFNs and
SSNs (for the U.S.) are supposed to map TO a unique individual (although the
reverse mapping is not unique; a person may have multiple AFNs, etc.).

[Peter J. Seymour]

"D. Stussy" wrote:

As far as INTERNAL numbers go for the operation of the program, they should
probably be (32-bit unsigned "integers") whole numbers starting at 1 for the
first person (reserving zero to mean NULL when used as a "person pointer") and
stop at the last person entered, however many that is. With 32 bits, one can
reach 4 billion, and I seriously doubt that one will ever get a single database
with that many people linked in. (I don't see 64-bit numbers as necessary.)

I considered this, but concluded that the file used to save the state of
the counter between executions was too liable to possible damage or
loss. What I have decided to do for the internal ref is to use a 'record
creation' timestamp. Since the Java time resolution is not good enough
to ensure unique ids, I tag onto the end the value of an incremented
counter. The result is what amounts to a 64-bit field. In my data model
this is represented externally as character, so I compress it using 62
bit (0-9,A-Z,a-z) encoding to save space. This saves 8 bytes per record.
The scheme ensures that 'out-and-back' merging can be handled reliably.
Regards
Peter

[Peter J. Seymour]

"D. Stussy" wrote:

There are certain things that ARE supposed to be "keys" in nature: AFNs and
SSNs (for the U.S.) are supposed to map TO a unique individual (although the
reverse mapping is not unique; a person may have multiple AFNs, etc.).

In the UK there is the NI (National Insurance) number among others
Regards
Peter