The Rules
I’m somebody who believes in absolutes. My old boss used to tell me that I saw the world in terms of black and white while ignoring the gray. He’s probably right. I think being anal-retentive about things makes me a better DBA.
There are a few rules that I believe in and don’t like to budge on.
- Developers don’t touch production. Ever.
- We don’t install objects in the MASTER or MSDB databases. It’s too easy to create a database opposed to polluting system databases.
- We don’t make system changes during peak use times. Changes go in during off-hours or maintenance windows.
- The fewer people who have the SA and service account passwords, the better.
- If you need a login to a database server, it’s going to be your active directory account.
- Use triggers sparingly.
- Triggers don’t send mail. Ever. Your users will have a bad experience should the Exchange server go down. Instead, use the trigger to write to a queue table and use a scheduled task to send e-mail.
- Database servers and web servers can be friends, but they shouldn’t live together.
- If I can’t justify something to an auditor, you can’t do it.
Those are some of my rules. What are the rules in your environment?
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.
Comments
I agree wholeheartedly, thuugh I violate your no email in triggers rule in my management code. However, there is no user experience associated with my management code or the emails generated to my by my server. I would never do such a thing in a business database, it just fit my needs years ago and I have no intention of fixing something that isn’t broken. Great list of rules.
Sorry, the comment form is closed at this time.
I agree that being a little anal-retentive is what makes better DBAs.
I would say how strictly the rules are enforced are also a product of how big/small the environment is that you’re working in and how much of a commitment from management you’ve gotten for your rules.
One rule I would add is to adhere to the defined naming conventions. If a developer names an object something like “SuperDuperObject”, it doesn’t help anyone in the long run. I hate when I’m asked to create a report and I need to find some table or view that is just poorly named. And if that developer moves on, who else is going to know what that object is there for?