+972 52-548-6969
Per Application Database
Scott Bellware is talking about application embedded databases, an application that is the sole domain of the application that is using it. I don't like the term, because embedded databases have another meaning, but I fully support the idea that the database should be an implementation detail of the applications.
I had a project where we needed to use an existing database, and I want to cry when I think about the length and breath of of effort that we had to go through to get it to really work.
In the last project, I have had at one time to change the DB password daily, to keep [Some Other Party] from trying to integrate with the application through the database. (In the end, we create a separate database, just for them, and they integrate through it).
The problems with per application databases are silos and getting the data out to other applications. This bring us back to the data outlives the application, etc. I have a longer post in the pipeline that is going to talk about that.
Comments
I've seen too many systems to believe that applications can really ever fully encapsulate their databases without causing introducing other problems. Application designers seldom foresee all of the creative future uses of the data they are manipulating. All too often, application-provided data access APIs end up being too restrictive or too leaky.
Data wants to be free. (But how?)
Jeff,
Then move the data away from the application database, to a data warehoure, where you can do whatever you want with it.
The problem is constraining the application and forcing a bad model on it.
Comment preview