3 ms·
And the number of rows in the table, effectively bloating it for all time. Deleting rows should generally be via the same type of query patterns you use to fin
by hobs 3y ago
And the number of rows in the table, effectively bloating it for all time.
Deleting rows should generally be via the same type of query patterns you use to find them, or that's pretty weird.
I think #4 is something that most people dont implement - ime they just tombstone in their own table, and then all of the other problems are pretty rampant.
Having separate indexes for deletes might be a thing, but taking a history of every change to a thing in a relational way is still a big pain because of the schema cost, merging changes in an audit table when its really a slowly changing dimension is really weird to most query patterns.
To #2 - it depends on your query engine, but if every query does have filtered indexes there's still a cost to having two tables in one table (ignoring #4)
- hinkley 3y ago> And the number of rows in the table, effectively bloating it for all time. Particularly in the case of growth oriented companies, if your user base is growing exponentially, then half of your records are less than a year old anyway. This bloat is not the problem you make it. And as I said elsewhere, a row that is tombstoned can be deleted offline at some cadence that doesn’t break your other workflows. For instance when nearly all of its siblings are also dead.
- hobs 3y agoUsers per second and rows per second are not really that strongly correlated - plenty of services create an excessive amount of noise for a fairly low amount of "real rows". You can push on devs to fix things like pointless logical updates but its really easy to have a rogue process create copies of your entire dataset each time it runs.