Nope, the real problem is using a language/dal/design that doesn't allow you to add stuff w/o rebulding
the whole castle.
I routinely add fields to databases w/o impacting running code. I remember having to prove to a
customer that the latest database schema update could run the current code and that no data migration
was required to run the latest release afterward.
It's called good design which should encompass these type of potential problems well before putting
your hairs on fire.
If you commit yourself to tools that are rigid, guess what ? You end up with rigid apps. 😬
ORM are a good exmaple of a no-go for me after a single experiment.
Any slight schema change could screw up your running app.
Any process control after that bad architecture decision is essentially trying to correct
a problem that should not exist. I.e. a waste of time & money.
A bit of forward thinking can save a lot of Advil intakes... 😬
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nope, the real problem is using a language/dal/design that doesn't allow you to add stuff w/o rebulding
the whole castle.
I routinely add fields to databases w/o impacting running code. I remember having to prove to a
customer that the latest database schema update could run the current code and that no data migration
was required to run the latest release afterward.
It's called good design which should encompass these type of potential problems well before putting
your hairs on fire.
If you commit yourself to tools that are rigid, guess what ? You end up with rigid apps. 😬
ORM are a good exmaple of a no-go for me after a single experiment.
Any slight schema change could screw up your running app.
Any process control after that bad architecture decision is essentially trying to correct
a problem that should not exist. I.e. a waste of time & money.
A bit of forward thinking can save a lot of Advil intakes... 😬