Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
nlocklin
Yak Posting Veteran
69 Posts |
 Posted - 2001-11-05 : 14:37:39
|
| I have been given the task of developing a set of Standard Operating Procedures for Database Development and Management at the research project where I work. I think it's a great idea, and as the DBA for the group I'm glad that they're willing to commit to paper a set of standard procedures that everyone should follow. I can see it making my job a lot easier. That having been said, I'm struggling a little bit with what all should go into an SOP for SQL Server development.I've spent a good deal of time thinking about it, but I still haven't put much together that I'm happy with. Since most people here seem to have a lot more experience working with multiple developers (in previous jobs I've only had one or two, so it wasn't such a big deal) and from different perspectives, I'm interested in everyone's feedback... what should go into an SOP?My environment is as follows: I work for a clinical trials group with a Programming department of about 10 programmers, some with a year or so of SQL experience, some with none. They are all pretty good programmers. Their current environment is System 1032 on a VAX with their programs written in Fortran (one of them is excited about Fortran.NET - it's being released, honest to God). We're moving to SQL Server, ASP, VB, and Access.Some of the things I'm thinking about including are:Object Naming Conventions:I've looked at a lot of different ways that people standardize object names and pretty much came up with the conclusion that the particular naming scheme you settle on doesn't matter as much as just having a scheme to begin with. I kind of prefer adding prefixes like tbl (how else do you distinguish between a table and a view when reading someone's SQL code without looking at the objects), and like using singular names, but maybe I'm just weird.Object Ownership:Objects should be owned by dbo, unless there's a compelling reason for them not to be. SQLServerCentral has a great article:[url]http://www.sqlservercentral.com/columnists/awarren/worstpracticesobjectsnotownedbydbo.asp[/url]Object Descriptions:Objects that must be given descriptions before going to a production environment include Columns, DTS packages, and SQL Server Agent jobs. What else am I missing?Object Creation:Development will be done on a development/staging server, and objects will be reviewed by the Programming Supervisor and/or DBA before being moved to the Production server.Logins:I'm thinking about using NT authentication for read access to the databases, and giving users who require it a SQL Server account for ddladmin or dbo privileges on the development server. I have to allow our statisticians to have direct access to the tables (even though they don't understand relational databases... I can see that getting interesting) with read-only access.Any thoughts?--"It's not that I'm lazy, it's that I just don't care." |
|
|
|
|
|
|
|
Standard Operating Procedures for SQL Server