Kevin Dangoor wrote:
Actually, I do think that both styles (application database,
integration database) have merit for certain apps. Here's where
application databases make some amount of sense:
1) newfangled, "Web 2.0" applications and web services. Things like
Backpack (surprise, surprise!), where the application serves a
distinct purpose and lives out on the net. Data I/O is all done via
web requests that go through the application code, which ensures the
integrity of the data (to whatever extent it has been programmed to do
so).
As far as things like Basecamp go, at least part of the reason I'm not
using it myself is because of this attitude about data integrity.
Again, I think David is a brilliant guy, but that doesn't make up for
the years of domain-specific experience and wide user-base available to
the database developers. Any problem at the application layer (which is
where most problems seem to occur) can cause data integrity issues
unless the database itself is enforcing those rules. To be certain, I
can understand his reluctance to use stored procedures and would even
grant him that part of the argument. But foreign keys? Really. Those
belong in the database: they are *not* "business logic" nor are they as
easily (or efficiently, I might add) enforced from outside the database.
If the app fails I can restart it. If it takes my data with it, I've
got problems. If my company depends on project management software, it
won't be written by a MySQL guy, no matter how smart he is.
2) small office applications. I did a lot of work on billing systems
for doctors offices. Those systems are (or, at least, were) quite
self-contained and the people in the office tended to use those apps
for everything and not be computer literate enough to do much outside
of there beyond word processing. (That's a generalization, certainly.)
I have almost the exact opposite experience. The small office is where
I've almost always found a mishmash of Access databases, Excel
spreadsheets, etc, some of them sharing data, some not (and most poorly
designed, because the people who designed them really should have stuck
to word-processing). When migrating these systems to a centralized
system, there is always a large overlap where the centralized system
starts taking over functionality but parts remain elsewhere until they
are eventually brought into the fold. I think David's argument falls
apart there as well. If it were always starting from scratch or there
were a specific cut-over date, then I'd be more likely to agree, but
I've rarely encountered that. They always want the old system left
intact "just in case the new system has flaws", or they need some
feature of the new system right away, etc, but the problem of data
syncronization requires some integration of the existing infrastructure
(or creation of infrastructure which brings stray applications into the
fold during the migration period, which can often be months).
Now, these two points are what you mean by "highly specific,
non-enterprise type of application", but I wanted to break it out more
and emphasize that there's *a lot* of this, and #1 is still a growing
category.
Absolutely. Still, I'd wager that even these databases will one day
outgrow this category. Data outlives the app that created it, almost
every single time. These relationships need to be defined along with
the data *in the database* if you are at all concerned about the poor
sap who will have to one day retire your app or integrate it with other
software.
The larger the organization, the more likely it is to move into the
"integration database' category. A big organization *could* decide to
expose the database entirely via web services and use that layer to
maintain the database, or it could opt to move more into stored
procedures, triggers and the like to make the database engine do the
work. So, even within big organizations, there's still a choice to be
made that could enable the "application database" perspective.
Yes, but then so much for DRY ;-) David's argument puts you in the
position to choose between DRY and data integrity. I don't think this
choice needs to be made or should be made. At least one friend of mine
does just this. He defines the constraints in both PostgreSQL and also
in the Rails model. Not a big deal in terms of a workaround, but not
very DRY either. If this were an insurmountable issue, I'd call it fair
and move on. Since it's not even remotely insurmountable, but rather
just one guy's rather poorly thought-out opinion about where the line
between business logic and relational logic lay, I'll pass ;-)
Regards,
Cliff
