Comment by gorgoiler

Comment by gorgoiler 3 months ago

Additionally, mutable fields will quite often benefit from having a separate edit table which records the old value, the new value, who changed it, and when. Your main table’s created and updated times can be a function of (or a complement to) the edit table.

It is tempting to supernormalize everything into the relations object(id, type) and edit(time, actor_id, object_id, key, value). This is getting dangerously and excitingly close to a graph database implemented in a relational database! Implement one at your peril — what you gain in schemaless freedom you also lose in terms of having the underlying database engine no longer enforcing consistency on your behalf.

crabmusket 3 months ago

> This is getting dangerously and excitingly close to a graph database implemented in a relational database!

This feels like a great unresolved tension in database / backend design - or maybe I'm just not sophisticated enough to notice the solutions?

Is the solution event sourcing and using the relational database as a "read model" only? Is that where the truly sophisticated application developers are at? Is it really overkill for everybody not working in finance? Or is there just not a framework that's made it super easy yet?

Users demand flexible schemas - should we tell them no?

Reply View 0 replies

wavemode 3 months ago

> supernormalize everything into the relations object(id, type) and edit(time, actor_id, object_id, key, value)

I frankly hate this sort of thing whenever I see it. Software engineers have a tendency to optimize for the wrong things.

Generic relations reduce the number of tables in the database. But who cares about the number of tables in the database? Are we paying per table? Optimize for the data model actually being understandable and consistently enforced (+ bonus points for ease of querying).

Reply View 0 replies

motorest 3 months ago

> Additionally, mutable fields will quite often benefit from having a separate edit table which records the old value, the new value, who changed it, and when.

Aren't you describing a non-functional approach to event sourcing? I mean, if the whole point of your system is to track events that caused changes, why isn't your system built around handling events that cause changes?

Reply View 0 replies