Category: Learning

Brent Ozar shares some thoughts:

I’m not talking just about Microsoft SQL Server specifically here, nor T-SQL. Let’s zoom out a little and think bigger picture for a second: is the SQL language itself a problem?

Sometimes when I talk to client developers, they gripe about the antiquated language.

Brent goes on to list some common complaints with SQL in general and explains why there isn’t a better solution.

I should note that he also summarizes Feasel’s Law near the end of the post:

Remember when NoSQL came out, and everybody was all “databases r doomd”? And remember what business users said when they wanted to run their reports? NoSQL persistence layers pretty quickly changed their tune, saying, “Oh, well, uh, we meant Not Only SQL, that’s what we meant,” as they struggled to quickly slap in SQL compatibility. Even MongoDB, king of NoSQL, implemented SQL support.

Comments closed

Steve Jones works with Steve Rezhener:

Steve Rezhener put together a survey for what topics you’d like to learn about. A few others, including myself, gave him feedback and he’s published this for people to use. It was intended for SQL Saturday organizers and speakers, but it can work well for anyone producing information. I’ve created some shortlinks at SQL Saturday that you can use to take the survey and see the results.

• https://sqlsaturday.com/survey
• https://sqlsaturday.com/surveyresult

I’m promoting this because when I initially got the e-mail for it, I thought it was spam. With enough responses, this may help organizers focus in on specific topics for events, at least to some extent.

Comments closed

Robert Haas talks about a development challenge:

Hacking on PostgreSQL is really hard. I think a lot of people would agree with this statement, not all for the same reasons. Some might point to the character of discourse on the mailing list, others to the shortage of patch reviewers, and others still to the difficulty of getting the attention of a committer, or of feeling like a hostage to some committer’s whimsy. All of these are problems, but today I want to focus on the purely technical aspect of the problem: the extreme difficulty of writing reasonably correct patches.

Read on for Robert’s experience developing incremental backups in Postgres. In fairness, I think this is true of any complex system which becomes mission-critical. It’s really easy to develop in low-risk, limited-code, greenfield environments. As you change each of those properties, development gets considerably more challenging, even if people are doing the right things the right way and checking ego at the door.

Comments closed

Joey D’Antoni has some advice:

In the last few weeks, I’ve been at several conferences, such as the MVP Summit and SQLBits, and have watched many demos. I’ve noticed a trend in the previous couple of years where presenters use more recorded demos than in the past. This trend is mainly something I’ve noticed with members of the Microsoft Fabric team, but I’ve seen others do it as well. When you do it correctly, only the keenest eyes in the room will notice that you aren’t doing live demos. When you do it poorly, everyone’s eyes quickly divert to their phones, losing the audience.

Click through for Joey’s advice. Mine differs from Joey’s in one aspect: I actually record the audio before the video. I used to use Joey’s approach but flipped and found it’s actually easier to do it the opposite way. For my YouTube videos, the basic workflow is:

• Build out the demo I’ll show. Use this to get a feel for how long things should take
• Script out each section, including intro, demo, and outro
• Record each audio segment separately
• Play the demo audio segment and go through the demo. When I do this, I have the audio input muted so my screen recording has no audio track
• Splice together the audio and video tracks. Sometimes, I’ll have minor changes, such as needing to pause the video while waiting for a demo step to finish

It took me a dozen or so videos to get this system down but it does work really well.

Comments closed

Eitan Blumin lets me quote one of my favorite chapter headings from Adam Smith:

You see, in this past decade or so, we’ve all noticed a trend where more and more businesses are looking for DBAs who know a bit about everything: RDBMS, NoSQL, Key-Value databases, Cache Databases, Full-Text Search Databases, Vector Databases, and more. In response, more and more data professionals prefer to become multi-disciplinary, doing a bit of everything… Even if it means becoming a part-time Data Engineer / Data Analyst / Data Scientist / DevOps / whatever. Otherwise, they fear that they won’t be able to find enough job opportunities.

But, there’s a cost to that approach. Sometimes a very high cost.

Eitan argues in favor of an approach with part-time experts and full-time jacks-of-many-trades. For smaller companies, I completely agree: a software development company with 5 total employees usually can’t afford a full-time DBA or networking specialist or virtualization specialist, but they can still run into problems that an expert would easily be able to solve. But I think once you get past a couple dozen IT people at a company, there’s enough scope for some critical specialization. In other words, the market within a company grows (hush, people who are going to throw Ronald Coase at me for that statement—it’s metaphorical!) and allows for additional division of labor and specialization.

Anyhow, Eitan has some tips around determining whether you’d rather be a jack-of-all-trades or a master of something.

Comments closed

Phil Booth shares some recommendations:

First, let’s establish what the point of code review is and also what it isn’t.

The number one, most important reason to review code is shared ownership. “Ownership” can be tricky to define in code terms, but mostly it’s a feeling. It means you understand the code, that you feel empowered to change it and the responsibility to maintain it.

Click through for Phil’s thoughts on what makes for a good code review. I’ve found that the over-the-shoulder code review isn’t nearly as effective as you’d hope, and a proper code review can take a considerable amount of time, up to hours or days for a large change.

Comments closed