Share your stories + is it bad to have multiple dbs?

来源：http://www.imcoder.org/architecture/187115.htm

Q:
I am a young and ambitious developer building a large web app as a personal project/site and I am sure that there are plenty of experienced web developers on here.

Having read this section very often, I have seen some good advice provided by experienced individuals (professionals). Perhaps some of you can share your experiences and lessons learnt on delivering large web apps? Would make for a good thread if this can take off. :)

Also, what I was wondering was, would it be a good idea to have seperatedatabases for each of my web app's "systems"? I.E. the ad managementservice has its own table, as does the newsletter system.

A:
I believe if the tables were not related to each other then we can easily keep some data in another database. Like for example if we make a website and also plan to log Ipaddress etc of visitors. Now the logging tables can easily be kept in another database. This helps keep the size of database under control and also make thing a little faster in execution since only database is not under attack for all the queries.

A:

Yes, BUT...

If your database is under attack from all the queries i suggest better programming or not running it on a PDA: Seriously, if you have that on a modern computer or a shared host that possibly is a pretty irrelevant point for anything but a LARGE database, and output caching and smart programming can take out even more pressure.

The negatives are hugh:

It means a lot more open connections.

It possibly means getting distributed transactions into place, which are a LOT more heavy in terms of resources used than in database transactions.

It makes backup/restore of a defined moment in time pretty much something to write a thesis on, not something you just do.

I would generally say, keep to one database for one system. If necessary use schemas to isolate tables, or use prefixes. Use a central database if necessary to orchestrate systems, like sharepoint does: one for management, one for every content store. Or like MS CRM 4.0 does: one for management, one for every "entity" that runs a CRM instance.

But to split logging, newsletter etc. into different databases is just not necessary.

A:

I totally agree here, you will find that generally development and management are much simpler when using the minimum number of databases. There does come a point of diminishing returns however when the sheer number of tables/views/stored procedures in your database makes management a nightmare.

In general if find that databases tend to seperate themselves quite logically anyway. For example we have one DB for all our intranet site stuff (news alerts, page contents, adverts, user info) and then another one for our contract support system. The CS system and the intranet DB very rarely need to interact so its easier keeping them seperate, especially if we will ever need to move the CS system elsewhere (where the intranet may not be present), on the other hand if we had split the Intranet DB into smaller sections we would have ended up constantly opening new DB connections and wasting resources.

A:
I reckon it would be best to keep to one database, because most of these "systems" would need to interact with the user tables.

So far, I have designed one schema which has the user registration tables, and all the table for the prime user functionality of the system. The frontend extra systems like newsletter would need to relate to the user tables so I guess that gives me my answer.

Would partitioning be a useful issue to think about?

BTW this forum and this section in particular is great, because a lot of the stuff I've picked up from here and learnt I would never learn from reading books but only from years of experience (need a few more yrs of that).

A:
To be honest I tend to think of user data as immune from this kind of discussion as it will be needed from almost every app you build, its that special case.

At the risk of taking this off topic, my thoughts on how user management should be handled in large intranet(mainly) based situations. This isn't how we operate, but if I was to start over I'd think carefully about these topics.

User data should be in either its own DB or part of a phonebook/contacts application.

I would have a standard interface for a User and implement a provider model. This way you can move your applications into a new environment and link into whatever user system is in place there. You could be grabbing the User information via webservices, from AD, out of a database, whatever.

The above providers should implement some form of caching to ensure that we aren't making two different data connections (at least) with every page request

Role information should be managed by the individual applications in whatever way they need.

I'm sure there is other data which should be handled like this, although I can't think of any at the moment.

A:
There is a lot of talk about seperation of concerns and how it helps with development and is a good habit to practise.

That's why I raised this thread. At the moment my database is diluted with multiple concerns. With the scale of the schema, the design is fraught with danger.

However, with user data in its own db, I would then have to be opening connections to multiple databases in the front end (ie a user would be using functionality in two seperate databases). This does seem like a waste of resources and a nightmare for me, the developer. However, seperate databases would mean cleaner database schemas which are easier to profile and diagnose.

I will have to have multiple databases as there are units of business processes which are too distinct ie logging and core functionality. However, the trick must be to not be using more than one database in the process of achieving one objective.