June 25, 2007 at 5:19 am
Hi there
Hmmm...How to explain this....
I am writing a standards document aimed at
1. internal staff responsible for evaluating/purchasing 3rd party applications which will use our production SQL servers
2.Internal staff responsible for sigining off on development of bespoke applications which will use our production SQL servers
The document is attempting to define requirements and preferences and to assign weighted scores to each heading addresses headings like
Cluster awareness
Application architecture/tiers
SQL Server authentication methods
Application Roles
Reliance on shared folders or binaries on the SQL servers
Object naming standards
Use of Indexes aand Keys
Scripted deployment and update
Passing MSBPA testing (reserved words, deprecated functions, ansi joins etc etc)
As an example here is the table I have defined for database Connectivity Authentication method - the weightings are arbitrarily assigned by me based on the amount of administrative/security overhead/balance that I feel they imply
Preference Level | Description | Weighting |
1 | Windows/Pass through Authentication User by User | 10 |
2 | Application Role Instantiation (Secure Config) | 9 |
3 | Pass Through Authentication – Single User | 6 |
4 | Application Role Instantiation (non-secure Config) | -2 |
5 | SQL Server Authentication – Multiple Logins | -4 |
6 | SQL: Server Authnetication – Single Login/multiple users | -4 |
So why am I posting?
1. Perhaps other readers have already completed this exercise and can add new headings that I have not considered - why reinvent the wheel etc. I have done a number of searches to try and find similiarly-themed documents and have never found any. Is this a thinly-veiled attempt to get other people to do my work for me? I'm not sure, I do know that I would value other opinions.
2. To foster debate about the role of the DBA in setting standards for application design - in many instances the application is designed and built before the DBA has any inolvement - the document is an attempt to mitigate the worst effects of this lack of involvement
3. To foster debate about the correct standards and values from the DBA's perpective
3. To enumerate the relevant headings and define best practices in this particular context.
Ultimately its an application damage limitation document. There is nothing worse than having to restore a database to a production cluster for a new application that is cluster unaware and which contains important unkeyed tables with 300 orphaned logins all with a password of null and which requires three different shared folders containing .bat files on the sql server etc etc etc and you ask yourself how the development firm got away with this.
Anyway enough ranting...
Barry
June 25, 2007 at 5:46 am
You can add the permissions and privileges given to the database server and objects. Add the level of user rights in the servers. Access to file and folder paths. How connection are to be made to the application. Who is responsible for what and the alternate resource responsible for the same. Your drp and lot more can be said in this document.
Cheers,
Sugeshkumar Rajendran
SQL Server MVP
http://sugeshkr.blogspot.com
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply