Advantages/Disadvantages to using more than one database

I have a content site where everything is currently in one SQL Server
DB. As I add features to the site, for example message boards and
blogging, does it make sense to put those features in a separate
database? What would I lose and gain in doing so? Thanks so much.

ErikErik Lautier (lautier@.gmail.com) writes:

Quote:

Originally Posted by

I have a content site where everything is currently in one SQL Server
DB. As I add features to the site, for example message boards and
blogging, does it make sense to put those features in a separate
database? What would I lose and gain in doing so? Thanks so much.

It's difficult to say without knowing more about the business as such.
But assuming that you have common concepts like users, and you may want
to have links between different entities, a single database makes life
simpler. Cross-databases references are messy.

But if the message board and the blogs are entirely unrelated, separate
databases may be a better idea.

One advantage of separate databases, is that if the message-board database
crashes, the blog database may still be available.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Erland Sommarskog wrote:

Quote:

Originally Posted by

Erik Lautier (lautier@.gmail.com) writes:

Quote:

Originally Posted by

I have a content site where everything is currently in one SQL Server
DB. As I add features to the site, for example message boards and
blogging, does it make sense to put those features in a separate
database? What would I lose and gain in doing so? Thanks so much.

>
It's difficult to say without knowing more about the business as such.
But assuming that you have common concepts like users, and you may want
to have links between different entities, a single database makes life
simpler. Cross-databases references are messy.
>
But if the message board and the blogs are entirely unrelated, separate
databases may be a better idea.
>
One advantage of separate databases, is that if the message-board database
crashes, the blog database may still be available.

Thanks Erland...what if the message board and blog were to sit in
subdomains - is that a stronger argument for using a different
database? My concern is that if the traffic builds, I wouldn't want
activity in one area to slow down other areas of the site; but I don't
want to sacrifice simplicity either. From the sound of it, there's no
hard and fast rule about this...I'm just trying to plan in the event I
get the traffic going. Easier to fix now than later. :)

Erik

Quote:

Originally Posted by

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
>
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

|||Erik Lautier (lautier@.gmail.com) writes:

Quote:

Originally Posted by

Thanks Erland...what if the message board and blog were to sit in
subdomains - is that a stronger argument for using a different
database? My concern is that if the traffic builds, I wouldn't want
activity in one area to slow down other areas of the site; but I don't
want to sacrifice simplicity either. From the sound of it, there's no
hard and fast rule about this...I'm just trying to plan in the event I
get the traffic going. Easier to fix now than later. :)

Subdomains? You mean like blogs.lautier.com, messageboard.lautier.com etc?
I can't see that that has anything to do with it.

If you are nervous that the bloggers would slow down the message board,
then the same or the different database does not matter, as long as they
are on the same server. And that would be an argument for different
databases: if you go for different databases from the start, it will be
simple to move the databases between servers.

But then the databases would be entirely independent. Things like storing
users and their profiles should probably be in a separate database, and
the middle tier would be responsible to pass that information to the
databases.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

Adult Content Filter

I want to create a message board designed for a church. Their concern was if people were to type in offensive words; they didn't want to display that particular post.

Does anyone have suggestions on the best way to run through a particular block of text, searching if an offensive word was present and then omitting the post?

Obviousily the front end would be a web app, but the back end dbase for this is M$ SQL Server 2000.

Any ideas or comments would be appreciated!U need a dictionary in your database, and a fulltext search engine to deal with the posted text, to find if the words in the dictionary appear in the text, and also the count of them. Then to decide if the text is clean.|||I would look to perl, ruby, or python for this solution. Perl handles strings very well and would be a natural for this task. You could do this on your web server and reject the post or give the author a chance to correct the indiscretion if there was a problem.|||Paul,
The webserver is running Win2K and IIS 5.0. Do you think some ASP code would work? What would be the most effiecient place for it to process? Client, Webserver or DBase side?

Thanks for the response.|||First of, I am NOT a WEB developer so I may not be the best person to answer this question.

The way I see this problem is you need to take a list of words and pass them over some text to see if you get a match. This does not sound like something a DB could do efficiently. I am 100% posative I could setup a DB solution in less than a day but I suspect that using Perl and Regulare Expresions would be a better answer. If you haven't used Perl or RegEx. both excel at string manipulation.

As for running the code on the client or web server, I personaly would choose the web server. It seems like the deployment and maintinance would be simplified.|||Thanks for the info. I will post with the solution I come up with. Then maybe some has some ideas on whether they can come up with something better!

Thanks again.