[matc]

This is what you are missing: > but that is always true

You may have an old form you can't change.

For example:

- 10 apps connected to the same database. Changing the model breaks 10 apps. And you may not have access to change the code to any of those apps.

- In healthcare, when either the database or app go down people literally die.

This isn't as easy as it gets: no database vendor has a solution for this to date.

(Edit: formatting)

[nl]

Okay.....

I'm not sure what your point is. As you say, this is hard, and no one else has a solution either.

But the nature of CouchDB can help here - views can be used to create backward compatible versions of new data, and reading a JSON document with extra fields won't break existing code.

It's true it's not magic, though, if that is what you are after.

Edit: I see now you are working on http://chronicdb.com/ which looks like it tackles this problem.

10 apps connected to the same database. Changing the model breaks 10 apps. And you may not have access to change the code to any of those apps.

"Database as an integration layer" is an antipattern that should always be avoided (except possibly in the case of reporting applications). CouchDB isn't unique there.

In healthcare, when either the database or app go down people literally die.

Yes, and? CouchDB is reliable, distributable, etc etc. If your point is that you should be careful when you upgrade, then yes, I agree.

[devs1010]

Adding extra JSON fields can break code if you have matching entity types, say in Java, for example, and its trying to "cast" those JSON objects to that data type I am fairly certain it will throw an exception if the JSON object has a field thats not in the Java type

[matc]

Views are the reflection of the light at the end of the tunnel, but solve less than half the problem to date. Views work on SELECT, but not on UPDATE/INSERT/DELETE.

Also, what makes you say that database as an integration layer should always be avoided?

[nl]

Also, what makes you say that database as an integration layer should always be avoided?

15 years of writing software. Every time I've had to deal with a shared database it has caused problems, and every time I've built a system avoiding that antipattern it has worked much better.

But it's not just me, here's some references:

Enterprise Integration Anti-Patterns # - The Shared Database: http://ianfnelson.com/archives/2010/11/08/shared-database/

Database as an IPC Antipattern (which is a subset of the broader shared database antipattern): http://en.wikipedia.org/wiki/Database-as-IPC

There is a good reason why SOA was created, and why exposing applications' data via defined interfaces is very popular.

[6ren]

Database-as-IPC is about the transport aspect, not the logical integration (which is the problem of back-compatibility).

Ian F Nelson's blog post is about a DB that is tightly-coupled to the app: “my” application is using NHibernate as an ORM layer, so until this invasion we have been able to perform database schema refactorings with relative impunity.

Conventionally, RDB schemas are designed in terms of the data itself, not a particular app. In the Enterprise (where RDB are most used), data typically outlives different applications for the same task over decades, often written in different languages. Typically, the data needs also to be accessed by several different applications.

But here I'm talking about logical back-compatibility (surviving version changes) - the blog makes good points about "caching and application-level security". Where those vary with the application, it makes sense to separate them from the DB. But like Database-as-IPC, they are closer to the transport layer than to logical structure.

[6ren]

Views work on UPDATE/INSERT/DELETE with some restrictions, in MySQL 5.0 anyway: http://dev.mysql.com/doc/refman/5.0/en/view-updatability.htm... More expensive RDB's might too.

(I should have included this link in my other reply on problems with updating aggregated queries).

[alexro]

That's what versioning is for, isn't it? You still can submit old data under the previous version, and old apps will works just fine as they won't see the new data.

New apps will have to deal with old versions somehow, or some back-end job will produce new data out of the old.

[matc]

If you change the schema then the old version of the app can break. For example, if two tables are merged together.

If one suggests old data and new data be stored separately then the door to data inconsistency opens.