3 ms·
This works to a limited extend and leads to a huge complexity explosion as soon as you go beyond a single table. Going down this route is soon gone eat much of
by panick21_ 2y ago
This works to a limited extend and leads to a huge complexity explosion as soon as you go beyond a single table. Going down this route is soon gone eat much of your complexity budget.
I worked on a hospital information system that did this for all forms, and the parts of the table had complex self referential links. Getting the actual history out of that thing was SQL hell.
- clusterhacks 2y agoI agree that this approach would be pretty unwieldy for a large/complex backend schema. It worked quite well for a smaller, in-house application and set of requirements. I think I probably would be perfectly happy using the approach again for our in-house applications if requirements for audit/history preservation needed to be built into a data model. I don't have a good feeling for when I might say "this data model is too large/complex for this approach." I might instead think more about what and how many subsystems are going to have direct access to the RDBMS as a cut-off? Hospital/medical research information systems (my day job is in the backends of these apps) seem to use backends with many compromises and poor db designs bolted on. I have also dealt with the horror of electronic data capture forms. My most recent headache has been a poor data model that ultimately wraps each form in a very ugly JSON blob. I've never seen anything that so completely lacks any residue of design . . .