November 10, 2010 at 8:49 am
We are brand new to Sharepoint, but with some SQL Server knowledge. We hired a consulting firm to install Sharepoint 2010 for us. They are not DBAs and have let Sharepoint wizards create the databases. As expected, all the names have GUIDs in them.
I have read a lot of "best practice" opinions online that talk about using DBA created databases for the back end. Our firm has sold us on the set-it-and-forget-it method, saying Microsoft wants to keep DBAs out of the tables and databases when it comes to Sharepoint.
I'd like to hear some real world suggestions to the pros/cons of letting Sharepoint create the databases vs. using DBA created databases, especially for Production Farm environments. Right now the database names look ugly, but should we really care? Is it easier (and safer) to just let Sharepoint do its thing, or take more control over it?
We are using it basically for intranet and custom internet applications. We will also be purchasing an Imaging system (Knowledgelake is being considered) that integrates with Sharepoint.
Thanks in advance for any help with this.
November 10, 2010 at 9:11 am
from my experience, having those crazy long names caused a problem for me.
I was tasked with creating a process that used TDP ( a backup solution from IBM ) which requires command prompt scripting. (you call the backup via an .exe that gets installed on the SQL Server)
anyways, having to call those names 'dynamically' was nasty. i am sure if i had more time i could have made something a bit more intelligent, but i really hated having to deal with those naming conventions...
November 10, 2010 at 9:19 am
another problem that i remember was backups in general.
the DBA's there liked to create maintenance plans that did t-log backups every 30 minutes. so, after SP created a new databases, that Agent Job would start failing until they logged into the instance and took a full....
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply