I have done some big contracts for large financial companies, and for most of them, ANY changes to the DB structure required extensive 3rd party testing and a change control process that sometimes took weeks.
But we did get a waiver for the use of DB 'code' like stored procedures and views, which only had to follow the standard development test / acceptance procedure by separate developer, end user and third party test teams. For me, the database is more immutable than the application logic and especially the GUI, so it pays to spend a lot of time up front on DB design. Past experience has also lead me to expect that the DBMS will have a much longer shelf life than the application language / toolsets used against it, or at least, over time the languages / toolsets tend to multiply. For my part, I like to spend a lot of tie in getting an optimal DB design, and also putting a lot of validation logic into the DB. I also like making expensive use of stored procedures, my experience is that for a data-intensive multi-tool application they are faster and more secure... On 23 April 2018 at 19:22, Sven R. Kunze <srku...@mail.de> wrote: > So far, I have nothing to add, but just one thing. See below: > > > On 09.04.2018 00:37, g...@luxsci.net wrote: > >> One advantage to using logic and functions in the db is that you can fix >> things immediately without having to make new application builds. That in >> itself is a huge advantage, IMO. >> > > This is actually not the case. You want to have those logic tested as > thoroughly as possible being so close to your precious data. > > So, you write migration code that substitutes the old logic, test the > whole package, if successful, deploy (and thus run the migration). > > Cheers, > Sven > >
