Re: Rationale for aversion to the central database?

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 <srkunze(at)mail(dot)de> wrote:

> So far, I have nothing to add, but just one thing. See below:
>
>
> On 09.04.2018 00:37, g(at)luxsci(dot)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
>
>