Which is Smarter - A separate DB or a TABLE?

[molder101]

To be completely honest, in the past all I have really worked with was multiple tables within a single database.

However, all things come to an end and such is the case. I am about to begin a project (labor of love) for the office where I work. The site itself is going to be quite complex and I would like to break it into the best (and most efficient parts) as possible.

So my question is, with the following in mind, what is the smartest way to tackle the database design - tables within a db or multiple dbs?

I am going to need the following (tables or databases) to store information:

Front-End
1) Client login information (and client info)
2) page text
3) testimonials
4) articles
5) companies (with ratings etc)
6) faqs

Back-End
1) users
2) quote information
3) requests (store in db, no email)
4) alerts
5) claim info

Obviously, some of these could easily be incorporated into a single db and the queries could be sent using a join to maximize efficiency.

- Is it smart to completely split the front-end and back-end dbs?
- Would it be a complete resource hog to have only one db with many tables?
- Would it be a greater security risk to implement the previous statement?
- Is it more difficult (less efficient) to access info from two databases on a single page (if necessary)?
- Any other suggestions?

*For security purposes, all information is going to be passed via 256-bit SSL (pending browser supports - 128-bit otherwise).*

All comments & suggestions are no doubt going to be useful as I tackle this "bear."

To get an idea of how the information is going to be implemented - check out http://www.marianoagency.com/new for the template (work in progress). As mentioned, though, it is going to be pretty substantial once all is said and done so any "help" is absolutely appreciated.

Mike

[longneck]

- Is it smart to completely split the front-end and back-end dbs?

it can be. the difficult of writing and managing an applicaiton is directly proportional to the amount of data the apps need to share. and it's even worse if you store teh data on two physically seperate servers.

- Would it be a complete resource hog to have only one db with many tables?

just having lots of tables (and trust me, you by no means qualify for "lots") is not itself a resource hog. a database becoms a hog when the server is not matched to the load.

- Would it be a greater security risk to implement the previous statement?

your question is configusing, but i think i know what you are asking. if you implemented the two databases on to physically seperate servers, then the backend one could be better secured than the front-end one (i.e., prohibiting access to anyone not on the local network). but it is still very possible to secure a DB server in such a way to be usable by both a front-end and back-end interface.

- Is it more difficult (less efficient) to access info from two databases on a single page (if necessary)?

if the DB's are on the same server, then slightly more difficult, and definitely potentially less efficient depending on the DB server. if the DB's are on seperate servers, then it's much more difficult and much less efficient.