History of SQL vindicates my GEDCOM deconstruction.
Apr 18, 2024 16:40:55 GMT -8
Post by Uncle Buddy on Apr 18, 2024 16:40:55 GMT -8
www.youtube.com/watch?v=z8L202FlmD4
This fascinating video outlines the birth of SQL and for the first time I see that GEDCOM was not a random stab in the dark but a product of dark ages database structuring trends: hierarchical instead of relational. Trees of nested structures instead of tables of related data.
One of the points I made in Luther's 95 Theses: the GEDCOM Deconstruction was that GEDCOM can represent one-to-many relationships but has no inherent ability to represent many-to-many relationships. The video says the same thing about the structures that RDBMS replaced.
GEDCOM was a product of its times. Today we are still eating leftovers. To put it bluntly, nobody even bothered to wash the dishes.
The fact that all genieware developers have a different data structure as a back-end for their apps is not a reason to keep using technology of the 1980s to transfer data. I don't believe genieware developers of today will adopt a better "standard" for representing data relationships in a family tree. But I do believe that the developers of today will not be the developers of tomorrow... because they won't bite the bullet and let the surgeon do the needed work.
It will be painful for all involved, but GEDCOM will be replaced, and if GEDCOM is replaced by a SQL database like UNIGEDS which represents real world relationships among data in a realistic way at a correct level of detail, then that event will usher in the golden age of genealogy.
The fact that the biggest players in McGenealogy embrace GEDCOM as enthusiastically as the little guys at the bottom means that I could be wrong. The status quo could remain untouched, or only fiddled-with in the current tepid fashion, for a long time to come. If my introduction of UNIGEDS and its gedcomoid mirror gedMOM never catch on and never inspire anyone to do anything, they will still have served their real purpose, which is to keep me entertained and give me something to complain about.
This fascinating video outlines the birth of SQL and for the first time I see that GEDCOM was not a random stab in the dark but a product of dark ages database structuring trends: hierarchical instead of relational. Trees of nested structures instead of tables of related data.
One of the points I made in Luther's 95 Theses: the GEDCOM Deconstruction was that GEDCOM can represent one-to-many relationships but has no inherent ability to represent many-to-many relationships. The video says the same thing about the structures that RDBMS replaced.
GEDCOM was a product of its times. Today we are still eating leftovers. To put it bluntly, nobody even bothered to wash the dishes.
The fact that all genieware developers have a different data structure as a back-end for their apps is not a reason to keep using technology of the 1980s to transfer data. I don't believe genieware developers of today will adopt a better "standard" for representing data relationships in a family tree. But I do believe that the developers of today will not be the developers of tomorrow... because they won't bite the bullet and let the surgeon do the needed work.
It will be painful for all involved, but GEDCOM will be replaced, and if GEDCOM is replaced by a SQL database like UNIGEDS which represents real world relationships among data in a realistic way at a correct level of detail, then that event will usher in the golden age of genealogy.
The fact that the biggest players in McGenealogy embrace GEDCOM as enthusiastically as the little guys at the bottom means that I could be wrong. The status quo could remain untouched, or only fiddled-with in the current tepid fashion, for a long time to come. If my introduction of UNIGEDS and its gedcomoid mirror gedMOM never catch on and never inspire anyone to do anything, they will still have served their real purpose, which is to keep me entertained and give me something to complain about.