I know that I can run the ‘re-build indexes’ tool, which does indeed fix the problem, but this should not be necessary. It is far from the most important bug, but I think that it should be on this list to be fixed.
There are many similar causes of the indexes not being updated correctly in real time. It seems that running the “re-build indexes” tool is considered to be the fix and that no further fix is required.
It has long seemed to me that RM should run the “re-build indexes” tool just for one person every time it exits from the Edit Person screen, It would use the exact same logic that is used for the full “re-build indexes” tool, but just for the one person. But unfortunately that’s not the way RM works.
It really isn’t difficult to write a database procedure that updates each of the fields contained in the index (and adds/deletes records in the index) at the same time that those fields are updated (or records inserted/deleted) in the main table that contains them.
This is really the most basic level of professionalism that we should expect from a software company, even a small one.
just depends on which is faster-- and yes it would seem like a small thing to fix BUT perhaps the thinking is that there will be more times when a birth/ death date is change and less times when a date will be removed and left empty–if you change the date it updates automatically–not saying it’s right…
The problem is denormalized data and then not using database triggers to keep it in sync.
But then unique indexes aren’t used to prevent “multiple primary names” etc.
I’m probably wrong, but I would quibble a bit with the characterization that this is a case of denormalized data.
The Birth fact and the Death fact are contained in the EventTable. The dates can include month and day. The dates can be ranges. The dates can include qualifiers such as before or after or about or estimated. There can be multiple instances of the Birth fact and the Death fact, for example when there is conflicting evidence about which dates are correct. There can be so-called text dates which are not dates at all but which are merely text.
The sidebar index contains a specific birth year and a specific death year. There is no month and day. The years cannot be ranges and the years cannot contain qualifiers such as before and after. There are no multiple years when there is conflicting evidence. Nothing is stored in the sidebar index when the dates are text dates. The birth year and death year for the sidebar index are stored in the NameTable so that different names for the same person can even have a different birth year and death year if that was indicated by the evidence.
I’m not sure what the most rigorous and formal definition of normalized data is except that to be normalized, each piece of data should only be stored once. So my quibble reduces down to the question of what exactly is the piece of data that is being stored more than once if the birth year and death year in the sidebar index is denormalized. Somehow or other, it seems to me that the exact birth and death year that are stored in the NameTable are not the same data as the birth and death dates that are stored in the EventTable and that therefore there is no denormalization.
So rather than the problem being denormalized data, it seems to me that the problem is simply a design error or a programming bug. The birth year and death year for a person in the sidebar index should be updated whenever the user exits the Edit Person screen. Period. Failure to do so is a design error or a programming bug.
A WikiPedia article on data normalization may be found at Wikipedia Article On Data Normalization It’s also easy to find many other good articles online about the same subject. For the most part, the articles are in agreement but some authors present perspectives that differ in minor ways.
Jerry-
Thanks for your perspective.
Only issue I have is that you left off half of my comment-
I certainly agree that if the app were bug free and it ran on reliable hardware, data representing the same information in different tables could be kept in sync. My understanding is that enforcing that synchronization inside the database is best practice.
Agreed. A database trigger would be a perfect solution for this problem. That way, setting the birth year and birth date fields wouldn’t depend on exiting the Edit Person screen. It would depend only on updates to a Birth fact or a Death fact.
