Re:Software engineering topics I changed my mind on
by tikhonj on Saturday January 23, 2021 @11:11PM
(#25889141)
You (mostly) don't have to deal with data migrations with statically typed languages. Releasing a new version of some code is usually easier than making structural changes to a database that's in active use.
Re:Software engineering topics I changed my mind on
by Chris_Newton on Sunday January 24, 2021 @06:13AM
(#25891102)
Releasing a new version of some code is usually easier than making structural changes to a database that's in active use.
Yes, and on top of that, code-only changes need to be internally consistent to make sense but DB schema changes almost inevitably require some corresponding code change as well to be useful. Then you have all the fun of trying to deploy both changes while keeping everything in sync and working throughout.
Re:Software engineering topics I changed my mind on
by busterarm on Saturday January 23, 2021 @11:09PM
(#25889122)
You've hit on something there as well, but essentially it comes down to forced rewrites and flexibility. We tend to choose the more flexible systems to avoid forced upfront work when changes are needed even when it's the wrong choice for the project in the long run.
Re:Software engineering topics I changed my mind on
by Falkon1313 on Sunday January 24, 2021 @04:05AM
(#25890513)
Eh, not so much databases, but in terms of code, super flexible 'all things to all people' generic abstractions tend to be a lot more work and a lot more difficult to debug than a tight solution tailored to the problem it's solving, written in domain terminology.
If only I had a nickel for every hour I've spent debugging abstractions and indirection that were just there for the sake of adding flexibility that would never be needed.
Wouldn't this apply if you are using a static typed language too? what's harder about changing the schema in the DB?