[eluser]Jay Turley[/eluser]
At my current position, I spent the first two years developing many small vertical applications for our internal use, each with their own database.
I spent the next two years refactoring the code and databases, bringing all of those applications into one common cross-enterprise application suite running off of a single database.
The reason is that it became apparent over time that many of the items in each separate application were related to items in other databases. The first suggestion was to create an API for each application so that information could be requested and sent cross-application. However, this had such a low ROI that we eventually just bit the bullet and brought them all into one tool.
So, my advice is, if you can GUARANTEE that these applications will never need to talk to each other, and that you will remain perfectly comfortable with such denormalized/redundant data repositories, then what the heck, go the 4 app / 4 db route.
If - on the other hand - you feel that you might eventually have to relate some of this information to other pieces, it may be worth biting the bullet and bringing all the data into one database.
It doesn't matter if you have 1 or X applications accessing it. One database is the way to go in my experience.
