• Your First Pipeline with Azure Data Factory
• Getting Started with CQRS – Part 3
• From the SQL Server Central Blogs - Using Pester to Improve Operational Tasks
• From the SQL Server Central Blogs - How to edit a connection in Azure Data Studio

• Tempdb Default Size

Daily Coping Tip

Remember that all feelings and situations pass in time.

I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate.

For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours.

Keeping Unique Aliases

I am a big standards guy. Not any particular standards, but ensuring you have some in your organization and that people stick to them. Pascal case, Camel case, it doesn't matter to me. I'll build a habit with any of them; I just want some consistency from others working in a team. Or even across teams since people move to different projects over time.

I ran across another post on naming conventions, this one looking at SQL standards, and it's a practical look at a few things. I like some of the ideas, like the singular or plural choice (" Who cares. Just pick one and use it consistently. "), but I especially like the idea of the third item: standard aliasing.

In the past, I've often found that I used the same aliases over and over. When I was the only DBA, this ensured consistency. "P" was always for dbo.Product, and pc was always used for ProductCategory. However, when we added other team members, I quickly realized we didn't use the same conventions. I'd check out code and see prod.productid instead of p.productid. The new people didn't like my single character aliases and I didn't like typing most of the word for theirs.

Ultimately we had to decide what made sense for both of us and compromise. We choose specific items, not all at once, but as needed. We'd have a 30s meeting or exchange a quick chat message and then update a document with the standards. When other new developers were hired, they already had a reference list that they quickly learned.

I think the idea of standard aliases makes sense. It's built into SQL Prompt and some other tools, precisely because many teams want to ensure their developers adhere to a standard, and more importantly, can quickly understand any code they pick up. That's the real reason for standards: they convey information, silently and quickly.

Steve Jones - SSC Editor

Join the debate, and respond to today's editorial on the forums