|
|
Browse by Tags
All Tags » habits (RSS)
-
In my last post in this series , I talked about inconsistent table aliasing. Today I was reminded of another behavior that DBAs and developers alike can be lazy about: keeping Books Online current. There are always going to be mistakes in any set of documentation,...( 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...
|
|
|
|