Press "Enter" to skip to content

Category: Naming

Power BI Datasets? Semantic Models!

Chris Webb shares some thoughts:

The name change proved to be surprisingly uncontroversial. Of course it’s very disruptive – trust me, I know, I have around 500 blog posts that I need to do a search-and-replace on at some point – so I have a lot of sympathy for people with books or training courses that need updating or who are getting calls from confused end users who are wondering where their datasets have gone. But there was a general consensus that the change was the right thing to do:

Read on for a bit more of the story, as well as some great links to get additional information on semantic modeling.

Leave a Comment

Naming Artifacts in Microsoft Fabric

Johnny Winter shares some advice:

With Fabric being a unified platform, the worlds of Power BI Developer and Data Engineer collide. So is a solid naming convention a good idea?

At Advancing Analytics, we say yes.

In fact, given the breadth of the platform and the variety of artifacts available for use in Fabric, it becomes even more important to have a strategy to be able to organise these items and make them quick and easy to identify.

Read on to see what Johnny recommends.

Comments closed

Don’t Start Stored Procedure Names with sp_

Chad Callihan provides solid advice:

Everyone has an opinion on naming stored procedures. One opinion that can be agreed upon is that starting a stored procedure with “sp_” is not the way to go. Using “sp_” can only do harm. Let’s take a look at why that is.

Read on for Chad’s reasoning.

I don’t like prefixes at all for stored procedures (or tables). It’s a common misunderstanding of Hungarian notation, as you don’t provide any new and relevant information in the object name: of course it’s a stored procedure; I’m using “EXEC” to execute it, so what else could it be?

The exception to a very good rule is something which you intend to put in the master database and execute from any database context. The best example of this is sp_whoisactive.

Comments closed

Role Analysis: DBA, Data Engineer, DB Reliability Engineer

Kendra Little disambiguates roles:

Much has changed: development patterns transformed from Waterfall to Agile, DevOps drives automation and shared ownership of code, and cloud services have made many more kinds of PAAS databases, data lakes, and data lakehouses available to organizations of all sizes.

These changes have introduced new and varied career paths for data folks which have different emphases on skill sets. In this post, I talk through the commonalities and differences between DBAs, Database Reliability Engineers (DBREs), and Data Engineers (DEs). Whether you’re a hiring manager or data professional, it’s worth knowing about these roles.

And a fourth one I’d include is Database Engineer, which I’ve also called a development DBA (versus a production DBA): focus on one platform, like SQL Server, and specialize in code development and tuning on that platform. I’d expect a Data Engineer to be familiar with at least one or two non-SQL programming languages—Python, Scala, Java, C#, F#, pick your poison—but that wouldn’t necessarily hold for a DBE.

Comments closed

The Importance of Naming Constraints in SQL Server

Eitan Blumin gives everything a name:

This article was published by Aaron Bertrand a few years ago, talking about system-named constraints in SQL Server.

The article mostly focuses on the issue of naming conventions as the main issue with system-named constraints and provides a useful stored procedure script to generate sp_rename commands for all system-named constraints.

However, the script in the article provides the solution for only one database and doesn’t support the new “Edge Constraints” that were introduced in SQL Server 2019.

Check out Aaron’s article and Eitan’s follow-up piece.

Comments closed

Unsupported Characters in Azure SQL DB Database Names

Nithya Bondalapati notes a discrepancy:

ARM (Azure Resource Manager) API does not support specific T-SQL resource naming formats and that’s why when Databases are created using T-SQL/SSMS, unsupported characters could get allowed into the names.
Azure Portal UI does not have this issue, because when you use Portal UI for creating a Database, the creation goes through ARM, and hence when unsupported characters are entered in the Name field, it immediately throws error, as shown in the below image.

None of the restrictions or onerous, but Nithya explains what actions fail or don’t quite work right if you have a database with special characters or ending in a period or space.

Comments closed

The Importance of Power BI Object Names

Paul Turley sends us an e-mail:

Using common language is critical but often trivialized, when describing requirements, deliverables and project expectations. When people are working together, depending on each other to complete important tasks, they must have a clear understanding of the common language and terminology. It is usually only after a word, phrase or abbreviation has been used with an assumed meaning that we realize the error and have gotten ourselves into trouble. Often, on a daily basis, I review project proposals and requirement documents containing inaccurate language related to Power BI project work. I also getting a lot of virtual eye-rolling when correcting seemingly inconsequential language. But I can also cite many cases when subtle misinterpretations became costly mistakes.

This is at a higher level than naming measures or dimensions.

Comments closed

What’s in a Name?

Benjamin Smith analyzes a name change:

Recently, RStudio announced its name change to Posit. For many this name change was accepted with open arms, but for some-not so. Being the statistician that I am I decided to post a poll on LinkedIn to see the sentiment of my network. After running the poll for a week the results were in:

Read on for the responses as well as an analysis using RSTAN.

Comments closed