Database Location Recommendation | SQL Server Performance Forums

SQL Server Performance Forum – Threads Archive

Database Location Recommendation


There is a database on one of servers that has a single table in it. It’s tied to an intranet page. We have a second database with 2 tables in it also tied to intranet web pages. I would like to avoid having 20 databases with 1-2 tables in them for every web page that’s created. I want to avoid the situation of having 50+ single table databases to support internal web pages but at the same time I realize that the different databases are not related (so far) outside of their common usage of supporting the intranet. Is there a recommended practice for handling this type of situation. Has anyone else come across this? Thank you
Elizabeth

If each database is really used for a seperate site or application I would create seperate databases even if they are small. It’s easier from management perspective, application separation and troubleshooting. If a person screws up and deletes wrong data it’s easier to restore a backup and tlogs for the specific database than try and recover a specific table in a database used for multiple apps. Also troubleshooting performance problems is much easier if you don’t mix apps in the same database. Even the smallest database can bring down your SQL Server if the SQL code or app code is really bad.<br /><br />If they are not really seperate then you could create one or database holding all tables. Or maybe one database per "Intranet function" that hold related tables. If they are not related at all I wouldn’t put them in the same database. But it depends on how you define related I guess <img src=’/community/emoticons/emotion-1.gif’ alt=’:)‘ /><br /><br />We run 100+ small databases on one server that are for seperate websites but for the same customer. Much easier to troubleshoot application performance and restore data when needed.<br /><br />/Argyle
I would support Argyle in this case in terms of support & administration. _________
Satya SKJ
Moderator
SQL-Server-Performance.Com

Thank you and Satya for your reply. With the db’s being so very small I just wasn’t sure that they’re wasn’t a better way to handle it. From the perspective of recovery I can see the benefits much better. Thank you much. <br /><br /><br /><blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by Argyle</i><br /><br />If each database is really used for a seperate site or application I would create seperate databases even if they are small. It’s easier from management perspective, application separation and troubleshooting. If a person screws up and deletes wrong data it’s easier to restore a backup and tlogs for the specific database than try and recover a specific table in a database used for multiple apps. Also troubleshooting performance problems is much easier if you don’t mix apps in the same database. Even the smallest database can bring down your SQL Server if the SQL code or app code is really bad.<br /><br />If they are not really seperate then you could create one or database holding all tables. Or maybe one database per "Intranet function" that hold related tables. If they are not related at all I wouldn’t put them in the same database. But it depends on how you define related I guess <img src=’/community/emoticons/emotion-1.gif’ alt=’:)‘ /><br /><br />We run 100+ small databases on one server that are for seperate websites but for the same customer. Much easier to troubleshoot application performance and restore data when needed.<br /><br />/Argyle<br /><hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
]]>