Change Dates: Essential, Trivial, or Frivolous?
May 12, 2022 2:57:23 GMT -8
Post by Uncle Buddy on May 12, 2022 2:57:23 GMT -8
I'm not the sort of genealogist who ever took a second glance at a change date. I used to see the change dates created by Genbox ending up in notes when imported to online tree repositories. Very ugly. Notes should not be uglified by nasty import programs stuffing trivial junk into them. Notes are about the old folks back home. They are important. They are beautiful.
The change date is not about ancestors, so it's not what I'd call a primary feature of genieware. Nothing wrong with keeping track of our research, but does this feature have a real practical use? Is it arrogant for a researcher to track his every move? I have no opinion since I've never used it nor wanted to use it. But then, I haven't worn a watch since I was 8, when I wanted to be Huckleberry Finn and I couldn't see Huck wanting to keep track of what time he'd put his left foot in front of his right. This level of detail is kind of bureaucratish, even kind of WASPish, isn't it? That's not my official opinion, let's just call it a fleeting impression.
The database structure for the CHAN tag would be a little annoying to code because it is subordinate to other things but not something that would want a primary key. A primary key is for something you'd want to reference with a foreign key in more than one place. It seems that a change date has a one-to-one relationship with the change of data that it refers to. So it should be a column in a table where that data is recorded. So there would be a change_date column in several tables, e.g. person, source, place, note, and family if you have a family table. Normally, columns with the same name all contain foreign keys referencing a single piece of data stored somewhere as a primary key. But here we have repeated column names not being used that way.
I don't care to bother with showing a change date in Treebard right now, but what about recording imported change dates anyway so they can be queried and maybe even exported? In that case, did I get the part about the foreign key wrong? Here's what just occurred to me. What if there was a single change_date table with a date_changes column, or one for date and another for time since that's how GEDCOM imports it. The primary key might not be very useful, but what if you had the foreign keys to the source_id, person_id, family_id, place_id and note_id stored in the table?
That makes more sense. Normally I wouldn't use a foreign key table for one-to-one relationships, but in this case it would eliminate repeating column names from table to table, which has some value.
As for actually keeping track of the last time data was changed, it wouldn't be hard but it would be bloat. But that's not official. I'm just thinking out loud about... About the 1745 CHAN tags in a Genbox .ged file I have for a tree with only 641 people in it. The subordinate tags in the CHAN pile are nested up to five levels deep, and two of those levels are custom tags, thus requiring a bloated import procedure and/or an entry in an exception report. But you won't see me stuffing them into notes.
Is genealogy about the old folks way back when, or about the all-important researcher's every little move?
The change date is not about ancestors, so it's not what I'd call a primary feature of genieware. Nothing wrong with keeping track of our research, but does this feature have a real practical use? Is it arrogant for a researcher to track his every move? I have no opinion since I've never used it nor wanted to use it. But then, I haven't worn a watch since I was 8, when I wanted to be Huckleberry Finn and I couldn't see Huck wanting to keep track of what time he'd put his left foot in front of his right. This level of detail is kind of bureaucratish, even kind of WASPish, isn't it? That's not my official opinion, let's just call it a fleeting impression.
The database structure for the CHAN tag would be a little annoying to code because it is subordinate to other things but not something that would want a primary key. A primary key is for something you'd want to reference with a foreign key in more than one place. It seems that a change date has a one-to-one relationship with the change of data that it refers to. So it should be a column in a table where that data is recorded. So there would be a change_date column in several tables, e.g. person, source, place, note, and family if you have a family table. Normally, columns with the same name all contain foreign keys referencing a single piece of data stored somewhere as a primary key. But here we have repeated column names not being used that way.
I don't care to bother with showing a change date in Treebard right now, but what about recording imported change dates anyway so they can be queried and maybe even exported? In that case, did I get the part about the foreign key wrong? Here's what just occurred to me. What if there was a single change_date table with a date_changes column, or one for date and another for time since that's how GEDCOM imports it. The primary key might not be very useful, but what if you had the foreign keys to the source_id, person_id, family_id, place_id and note_id stored in the table?
That makes more sense. Normally I wouldn't use a foreign key table for one-to-one relationships, but in this case it would eliminate repeating column names from table to table, which has some value.
As for actually keeping track of the last time data was changed, it wouldn't be hard but it would be bloat. But that's not official. I'm just thinking out loud about... About the 1745 CHAN tags in a Genbox .ged file I have for a tree with only 641 people in it. The subordinate tags in the CHAN pile are nested up to five levels deep, and two of those levels are custom tags, thus requiring a bloated import procedure and/or an entry in an exception report. But you won't see me stuffing them into notes.
Is genealogy about the old folks way back when, or about the all-important researcher's every little move?