Differentiated identifiers considered "best practice" in Transact-SQL?

I am working on some legacy SQL, and the author restricts each column name and data type declaration. See the following:

  CREATE TABLE SomeTable (
     [SomeDate] [datetime] NOT NULL,
     [SomeInt] [int] NOT NULL,
     [SomeString] [nvarchar] NOT NULL
 ) ON [PRIMARY]
 GO

Is this considered best practice when writing T-SQL for SQL Server? Since I support this code, should I continue to practice?

+4
source share
5 answers

I personally will only write that if you use reserved keywords as column / table names, which you should not be anyway. Personally, I think that otherwise it makes the SQL code less "clean" and a little harder to read.

This style is typically created using SQL tools, as it ensures that there are no problems with reserved word conflicts.

+12
source

If the name of the table or column is "harmless", for example, "SomeInt", square brackets [...] not required, you can specify them if you want, not necessary.

On the other hand - always using them, make sure that even β€œdangerous” column names such as '[Message]' and others, or column names with spaces in them like [Product Name] will always be processed correctly.

So, you do not need to continue to do this, but I would think that it is good practice, and if it is already in use, I would recommend to continue to use it.

+4
source

Most of the MS tools that I worked with this SQL creation will do it automatically (old Query Analyzer, Management Studio, etc.) This will not hurt.

0
source

[SomeName] is what is automatically created by scripts from SQL Server Management Studio. Personally, I find this distracting and makes names more difficult to read.

The only real use for them is to allow spaces in identifiers.

i.e.

 create table SomeTable ( [some var] int ) 

is acceptable (albeit impractical) when

 create table SomeTable ( some var int ) 

wrong.

Thus, it would be useful to migrate / save old projects.

0
source

Just start with mssql / t-sql, and maybe the solution can use single quotes when necessary, as this applies to both the obsolete square bracket style and the new double quote style. Reply if I am wrong!

A simple example.

 1> sp_help sys.tables 2> go Msg 102, Level 15, State 1, Server Incorrect syntax near '.'. 1> sp_help 'sys.tables' 2> go Name Owner ------------------------------ ---- tables sys etc 
0
source

All Articles