Timeline for answer to Relational databases and iterative development by gbjbaanb
Current License: CC BY-SA 3.0
Post Revisions
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 22, 2016 at 10:37 | comment | added | Jan Hudec | You still have to go to each customer site to install the SP and add the new field. And when you are there, you can migrate the data too. SPs are useful in that they allow you to create backward compatible interface if you have multiple applications access the database, so you don't have to upgrade all of them at the same time. But they don't save any steps when the schema needs to change due to changing requirements. | |
| Feb 22, 2016 at 10:26 | comment | added | gbjbaanb | @JanHudec since when do SPs not live in version control? You can cover such things, you change the SP API to take a string and write it to a different field, handling the old numbers and new strings in a bit of code in your SP. Not the nicest, but it can be better than going to every customer site to migrate their data to the new string format (there are better examples, but you get the idea). If the change turns out to be big, then you have to migrate , but at least with a DB API you have other, cheaper, options too. | |
| Feb 22, 2016 at 10:14 | comment | added | Jan Hudec | The underlying scheme sometimes needs to be changed. As the application enters customer testing, new attributes crop up you've never heard of, attributes you thought were numbers turn out to be strings, relations you expected to be 1:1 turn out not to be so after all and so on. You can't cover this kind of things behind stored procedures (besides, stored procedures are part of the problem, because, like other things in the database, they don't live in version control). | |
| Feb 22, 2016 at 10:07 | history | answered | gbjbaanb | CC BY-SA 3.0 |