Can u send me the complete reference of ‘CREATE INDEX’ which session was taken by u on 3rd october.

You have announced that, if anybody will send me request me
i will send the comepete reference of ‘CREATE INDEX’ with Examples.

That is not how i see it at all. The TABLE merely defines the records within it, which each are, individually, one customer.

I do not like any prefixes – name stored procedures based on the table/object they most affect and what they do based on CRUD

CustomerGet (get one customer)
CustomerSelect (get more than one customer)
CustomerUpdate
CustomerAdd
CustomerDelete

The table is Customers (with the s, becuase that is what is in the table as a whole, the customers)

a view that joins between Customers and Accounts and groups on customer (where a customer can have more than one account). Since Customer is the group by it is listed first in the name

CustomersAccounts

Accounts and Customers listed by account, since account is the group by it is listed first in the name

AccountsCustomers

> Use following naming convention for Stored Procedure. sp_[_] Where action is: Get, Delete, Update, Write, Archive, Insert… i.e. verb

Use SCHEMAs, Luke :)

I’d like to see good old approach “fit all that info in that damn short name”. But I’ll not be happy if I find it in our projects. Precisely, I will be very, very unhappy :)

We prefer to spread our projects on several databases (the separation is based on domain scopes) and schemas (there are no strong rules, but we prefer to create separate schemas for each API segment).

Good luck, guys! Be happy:)

What About composite Primary Key

[
* Primary Key : PK_

Example:

PK_UserDetails

PK_ Emails
]
??

SELECT Username, Password
FROM UserDetails ud INNER JOIN
Employee e ON e.EmpID = ud.UserID

This was I can easily see which tables are included in the query.

Your suggestions are valuable.

Kind Regards,
Pinal

I appreciate your feedback. I will follow up on it.

Kind Regards,
Pinal

There is one intent on everything between the WHILE and the final END; and there are two indents on the INSERT.

IF (NOT EXISTS (SELECT 1 FROM [Subscription] (NOLOCK) WHERE ([CustomerID]=@CustomerID))) BEGIN
INSERT [Subscription] ([Guid], [CustomerID]) VALUES (@GUID, @CustomerID);
END;

FETCH NEXT FROM [MyCursor] INTO @CustomerID;
END;
——–

Very nice blog post. Standards in SQL are on area that people do not think about enough, so I’m very happy to see this. I’m also happy to see that many things I personally have as standards match up well to yours.

A little feedback on a few items you mentioned:

I have always used the table name to describe what is being stored in each individual row, rather than using the name to describe the container itself. That specifically eliminates the addition of an “s” at the end (in most cases). So I refer to the “customer” table, not the “customers” table.

For SP naming conventions, I like making the names a bit shorter and in a different order. The main goal for me is that the SPs are easy to group and find in SQL Server Management Studio. I actually use camelCase:

For example, if I’m writing a SP for the Google Web site, a SP name might be “googleEmailUpdate”.

By placing the Object/Table Name before the Acton, it is much easier to group and find the SPs in Management Studio. It does not flow off the tongue quite as nicely, but finding SPs is a breeze.

I normally use a “db” prefix for system maintenance SPs, and I use a “clr” prefix for (you guessed it) CLR code.

(@Atif: in Management Studio, the system SPs are separated from the user’s SPs — they are in a different folder — and they also use the “[sys].” prefix, so there shouldn’t be any conflict with naming, even if you stick with “sp”.)

Something you didn’t mention as a standard is the use of semi-colons. My personal standard is to use a semi-colon everywhere they are optional. Once you get into the habit, it is second-nature and not a bother at all. On the contrary, it provides more robust code, because if you don’t use semi-colons, you’re relying on the parser to determine the end of your statement.

One other area I would like to comment on is your last point, about using BEGIN … END only in cases where they surround multiple statements. I humbly disagree.

I have struggled with how to write BEGIN … END over the years, because they are visually clumsy. But I finally came up with a method that has proved to be helpful and visually helpful.

I *always* use BEGIN … END now, and I use them exactly like I use “{” and “}” brackets in C++/C# code. (K&R style)

I place the BEGIN on the same line as the conditional/loop/block, I indent all the contained code, and I align the “END;” (don’t forget semi-colons) with the block start.

For example (please ignore the code itself, which would be better served with a CTE):

WHILE (@@FETCH_STATUS = 0) BEGIN

IF (NOT EXISTS (SELECT 1 FROM [Subscription] (NOLOCK) WHERE ([CustomerID]=@CustomerID))) BEGIN
INSERT [Subscription] ([Guid], [CustomerID]) VALUES (@GUID, @CustomerID);
END;

FETCH NEXT FROM [MyCursor] INTO @CustomerID;
END;

You’ll also notice that another standard of mine is to place one blank line before and after any BEGIN … END block. That greatly enhances readability.

I’d suggest taking a complex SP you’ve written, and re-write it using my suggestions about BEGIN … END. Then compare the readability to the old version.

Thanks again for putting together this fantastic blog entry Dave!

-Todd (“Speednet”)

Regards

Regards
Chella Ganesh