3 ms·
One thing to pay attention to is the never-quite-done migration. For example, i worked on a deep refactoring (near rewrite) of a room reservation system where t
by Joeri 14y ago
One thing to pay attention to is the never-quite-done migration. For example, i worked on a deep refactoring (near rewrite) of a room reservation system where the data model needed restructuring for faster querying (but with identical data). The migration was done by making the old data model automatically write to the new from triggers, and then migrating the read code to point to the new. Ofcourse, once the performance bottleneck from the read code was solved, suddenly migrating the write code seemed way less important. Higher priorities intervened, and the code is still in a halfway state two years down the road.
Another danger i ran across were moving goal posts. Long rewrites will typically be interrupted to extend the old system with new features, which increase the effort to rewrite.
- philsnow 14y agoI don't know the specifics (obviously) but this reads like creating a better index on an existing table. The gross part is (I'm guessing, obviously) that now each write to this data store incurs an additional write and some cpu load on the data store servers (you mentioned it was done via a trigger). But now the value of finishing the migration that you started is just recovering this extra write and cpu.
- ams6110 14y agoAnd as an aside I'd strongly advise against using triggers in almost all cases. They tend to result in systems where things happen by "magic" rather than in well understood ways. If you're tempted to write a trigger, use a stored procedure instead and invoke it explicitly.
- Joeri 14y agoIt was actually about merging half a dozen tables into one (a fancy denormalization), and at the same time precalculating some fields. We had gone as far as we could with indexes. The write volume is not a big deal because writes are rare on a reservation system.