> In the split-up design, since you're not sharing the database, you can do whatever you want.

> we can't add a new field, we can't change this field

Ok, let's do an example.

Assumption:

A-ERP system with approximately 30 modules in use (e.g. sales order mgmt, inventory, purchasing, etc)

B-For split DB, the DB is split by module and data flows exist for all shared data. So there are X different copies of the item master (many and possibly most of those modules use the item master), each with the subset of data required by the specific module.

Sample change, add a new field to the item master:

Shared DB:

1-Update DB schema for item master

2-Update code in different modules that need to use the new data element (per feature requirements)

Split DB:

1-Update DB schema in all modules that require the new data element (per feature requirements)

2-Update code in different modules that need to use the new data element

3-Update the data flows for item data in each module that needs to use the new data element

I think you're understating the level of effort when you say "now we can do whatever we want". The actual effort in this change (which is a very common example) is actually greater than in a shared DB and requires more coordination.

Again, there are times when it's the right thing to do, but definitely not a silver bullet without trade-offs.

It's interesting to see what people consider difficult to do.

In my opinion the "Split DB" case you outlined is still much easier to do.

It's never the lines of code or number of steps that need to be done make it complicated or difficult.

It's always the strange, weird, unexpected things. I change "this" and "that" breaks, but nobody knows why.

The biggest benefit of my approach is that it can be split-up between people. One team handles this part, the other some other part. You can only break your part of the database, not everything for everyone else.