ARTICLES

Home  > Articles  >  The Top 10 Signs You Need Best Practices
The Top 10 Signs You Need Best Practices
 
Chris Shaw
Chris@SQLShaw.com
 
Five or six years ago SSWUG released a t-shirt that was really meant to poke fun at the number of easily avoided mistakes with databases. Over the last three versions of SQL Server the points remain the same, and they have proven that with careful planning a solid databases will stand the test of time. If you have found yourself in the position where you knew what the right thing to do was, but could not list the many of the reasons why, this series of articles is for you. If you are new to SQL Server and are looking for some best practices to stick by this series of articles is for you.  There are a number of features of SQL Server that are meant to be used in specific situations things like, No Lock and cursors. But when all is said and done know why you should avoid:
 
  1. Keeping permissions simple,  make all users DBO – As sad as it sounds I run into this more often each and every day. Microsoft has taken steps to lock down the ‘sa’ account but we have so far to go. I don’t think that many people understand the theory of the least permissions possible. In the security article we will discuss what we can do as DBA’s to get permissions under control.
  2. Never Use Stored Procs – I have been in many situations where I have been working on a new application or a new feature to an application and when I make a recommendation to utilize stored procedures someone always asks why. In the Stored Procedures article we will list a number of reasons why stored procedures will not only perform better but will give you an extra layer of security.
  3. Never use a where clause on Updates and Deletes statements – We won’t be dedicating an article to this subject, why? You should only make this mistake once. The first time I was teaching a class I was talking about the implicit transactions, it was a conversation that was really close to another SSWUG bullet to watch out for and that is leaving open transactions. During the class I had issued a delete statement while I had highlighted only the Delete clause. With the statement being an implicit transaction I was not able to roll back. It was at that point in the class we talked about the restore statement.   
  4. Never read execution plans- Over the summer of 2009 I worked with a company that was applying thousands of business rules. Each rule was delivered in a number of batches over thousands of lines of code. The application of the business rules had to be done each week after they had done a new batch insert. To process all the rules took 4 days. I was brought in to performance tune the stored procedures. How do you determine what procedure needs tuning? How do you determine if a procedure is using an index? These will be the discussion items for the for the execution plans article. We will also spend some time talking about a free tool from Microsoft that few people know about, to see what features it can deliver.
  5. Create nested transactions for best performance- When learning t-SQL many people find it easy to use nested transactions. These nested transactions may not be the fastest way to write a query. In this article we will talk about a number of mistakes that I have run across with working with t-sql.
  6. Always edit system tables – The system tables have been renamed since this list was created, however the information is still there for you to read. In this article we will talk about where you can find the information by using the system tables.
  7. Never check the error log files – Have you wondered about what your error logs say about your server? Do you check your error logs each day? How are you maintaining your error logs to make them more manageable? In this article we will discuss using your error logs to help manage your SQL Server.
  8. Never backup your system database – Who needs all that junk that resides in the system databases? I have never known anyone who does not mind recreating jobs, logins links to other servers, and all the other information the system databases store. In this article we will talk about what to back up, when to back it up and some of the strategies you should look at when working with your master, model, tempdb and MSDB databases.
  9. Grant all to Public – When it comes to object level permissions there are options such as using your schemas. Most of the information for the point will be covered in the article about keeping it simple, but keeping it secure. 
 
I look forward to writing about these issues and I hope along the way you get information that you can use immediately with your own databases. Please take a moment to rate this article and if there is a topic you would like to see in the future please do not hesitate to contact me. Chris@SQLShaw.com