|
|
Browse by Tags
All Tags » best practices (RSS)
-
Maybe I'm a little late to the party, but I thought I would share with you the most recent release of Microsoft's Best Practices Analyzer for SQL Server 2008 R2 (you can also read the original blog announcement from CSS ). Let me be clear: this tool is...( Read More...
|
-
In my last post in this series , I talked about using user-defined data types (alias types). Today I wanted to discuss many of the ways in which people subject their date and time columns to very inappropriate query methodologies. It's very easy to say,...( Read More...
|
-
In my last post in this series , I talked about using the visual designers in SSMS. This time, I wanted to treat the use of alias types. To clarify what I am talking about here, alias types used to be called " user-defined data types ." Then, when CLR...( Read More...
|
-
In my last post in this series , I talked about abusing triggers. This time I thought I would focus a bit on using the visual designers in SSMS. Table Designer My biggest problem with the Table Designer : many changes you make can force SQL Server to...( Read More...
|
-
In my last post in this series , I talked about choosing inappropriate data types. This time, I want to touch on a few ways that I see triggers being misused. Using a trigger at all A lot of people think that they need a trigger. They allow direct access...( Read More...
|
-
In my last post in this series , I talked about the assumptions many people make about IDENTITY columns. In this post, I want to focus on choosing data types. There are several areas where I see frequent mistakes in data type choice, and I'll mention...( Read More...
|
-
In my last post in this series , I talked about inconsistent naming conventions. This time I want to talk about a few of the assumptions people make when using IDENTITY columns, and what kind of trouble they can cause. IDENTITY will prevent gaps A lot...( Read More...
|
-
In my last post in this series , I talked about using the schema prefix, with particular focus on dbo-only systems. In this post, I want to treat the use of inconsistent naming conventions. Stored Procedures In one of the systems I've inherited, we have...( Read More...
|
-
In my last post in this series , I treated the dreadful SELECT * and other ways we get around typing out a column list. This time I want to discuss the use of the schema prefix. This has to do with both creating and referencing objects. Do not make any...( Read More...
|
-
In my last post in this series , I talking about inappropriately using SELECT, OUTPUT and RETURN in stored procedures. Today I wanted to talk about using SELECT * or omitting the column list entirely. Using SELECT * This is a typical operation when developing,...( Read More...
|
-
In my last post in this series , I covered the use of "bad" characters in entity names, such as spaces or dashes. In this post I will talk about using RETURN and OUTPUT inappropriately. Jamie Thomson touched on part of this pet peeve in response to one...( Read More...
|
-
In my last post in this series , I talked about defining varchar columns, parameters, or variables without length. Next I want to talk about using "bad" characters, like spaces or dashes, in entity names. Every once in a while, I see people who have issues...( Read More...
|
-
In my last post in this series , I talked about using meaningless table aliases. This time I'm going to talk about a pet peeve of mine: declaring varchar / nvarchar variables or parameters without specifying how many characters they should hold. Thankfully,...( Read More...
|
-
In my last post in this series , I talked about using old-style JOINs. Today I'd like to touch on using aliases. No, I don't mean fake passports and a life of crime, I mean using an alias as shorthand for referencing a table or view in a query. Some code...( Read More...
|
-
I am sure most veterans know better than to use old ANSI-89 JOIN syntax, such as: SELECT o.OrderID , od.ProductID FROM dbo.Orders AS o , dbo.OrderDetails AS d WHERE o.OrderDate >= '20091001' AND o.OrderID = od.ProductID ; One reason to avoid this syntax...( Read More...
|
|
|
|