Nope.
Not for a successful project.
Your database is a shared resource. Whatever application you started with,
you'll either add more applications, or the whole project will fail. I'm only
going to consider projects that succeed.
Back in 1969, E.F. Codd wrote a paper that revolutionized computing. It was
called,
A Relational Model of Data for Large, SHARED Data Banks.
I've put the emphasis on shared, just as Codd did by placing that word in the
title. The entire point of the relational databases was, and remains, to make
a common resource available to many applications in a standard, well-defined
(if sometimes quirky*) way.
It's what they do. It's all they ever do! And they absolutely
will
not stop…Oh, wait. That's the Terminator.
Back to relational databases.
Every once in awhile, some arrogant, ignorant young blowhard announces that he
(it's always, "he") is going to "free" databases from the "tyranny" of being a
shared resource. He's always dead wrong. Sometimes people realize this
quickly; others, it takes years. If the new coders are lucky, he doesn't
convince too many of them. If they're not, a whole lot of people form a whole
lot of bad habits.
If I were more mercenary, I would thank them, because
we get so much work
from this kind of design. I'm not. There is plenty of work for us to do
without bad designs.
Here's a typical example of what happens out in reality land.
A team builds a web application. It's the smoothest, grooviest web
application in the world. The end users absolutely love it. To aid capacity
planning, the people running the web site would like a report. Then another.
Then six more.
Soon, the manual process of writing those reports repels both the inner
laziness of the coders and the impatience of the people in charge of purse
strings, so they make a reporting application.
If the team started by designing a database,
one of whose
purposes was to support the web application, that task is easy. If they
failed in this duty, that task becomes as the labor of Sisyphus: onerous,
repetitive, boring, not to mention error-prone.
Tune in next time for the Awesome Secret of Planning Shared Resources.
* I know, Jeff. I know.
Talking about reporting: afters several years, I have to admit one thing: I haven't found anything better that MS Access. With VBA you can use in report sections and events, things are really easy, and the print preview is well done. I wish I could stay away from MS Access, though. What tool are you using?
Next to MS Access, there are other tools that work in the same way: http://www.tableausoftware.com/ and of course Crystal Reports. But I wish there was an open tool in this field, with web capabilities...
I'm with you on this one. The reporting in MS Access is very nice and really that's the only thing I can't live without in MS Office. I use it in a similar fashion to you -- against PostgreSQL or SQL Server or both in one MS Access db.
Plus there is the whole training thing. Have a lot of customers comfortable using it for queries and reports and so forth. It makes them feel liberated that they can query their own data (even against a powerful db as PostgreSQL) so we often just replace their backend and leave their MS Access front end and they can't really tell the difference. Open Office (OOBase) does it to some extent, but not as well yet. Not to mention people don't like to learn new things. There is a certain comfort in familiarity.
Free software tools tend to be of the "one small tool that does one thing well" design, which means that while you can do all those things, it's probably not terribly realistic to expect some giant application framework to be your "one stop shop" for doing it.
On the bright side, using many good tools, loosely coupled, you can make much better, more scalable applications than you could with something that tries to be all things to all people as Access does.
Since you are a judo black belt in Postgresql, I have a question in this field. When designing a system based heavily on database storage, when do you think you have better split your system into multiples subystems, loosly-coupled, taking into account that the splits brings a few side-effects too: if the subsystems are databases for example, you lose transaction integrity between the databases, and regarding reporting, joins start being problematic. The split could have an impact on performance, too: you can serve more users, sure, but a user alone has an application 10 times slower compared to a monolithic system, because of the numerous interfaces data has to cross before appearing on the screen.
I'm sure there is no definite answer to that, but with your experience, I'd be glad if your could share with us a few real-world examples.
Best regards,
Philippe
Check out JasperReports: http://jasperforge.org
In reality land it's not about applications, it's about servicing and doing what's good for organizations (or sub/supersets thereof, such as departments/groups) and managing data that their operation relies upon. You need to think within a whole different frame. Applications can be developed to a defined specification, but for organizations there will always arise new needs, reports being the clearest example. Once that is clear it's, to me at least, obvious that data is best handled by a shared and dedicated resource, the database, that is designed with that flexibility in mind.
Hm, I should blog stuff like this...