The Ebb and Flow of AI
It's the end of the year. Everybody's coasting and looking back. Let's kick our heels up, get comfortable, and talk big picture industry stuff.
You and me, our weirdo jobs involve:
It's the end of the year. Everybody's coasting and looking back. Let's kick our heels up, get comfortable, and talk big picture industry stuff.
You and me, our weirdo jobs involve:
Are your developers working with live production data, completely made-up synthetic data, or something in between? I posted a poll here on the blog and on a few of my social media feeds, and here were the results:
Note that the numbers can add up to more than 100% because folks could mark multiple choices if they had multiple teams with different approaches.
When your developers work on new queries or testing complaints about existing queries, what database are they working on?
I put together an anonymous one-question poll that only takes a few seconds to respond. Let me know! I'll follow up with a blog post about the responses.
I ran a poll over on LinkedIn to find out if people have 100% of their databases under some kind of source control or version control.
I broke the answers up into two sets, developers and non-developers, because I had a hunch that the developers' answers would be very different than the rest, and indeed they were:
"The last person must have set it up that way."
"The last person wrote that code."
I'm not talking about "oops" mistakes.
I'm talking about things you decided to do on purpose, and then deeply regretted later.
Managing what requests are made
Managing the efficiency of each request
Managing the hardware capacity available to satisfy requests
And that's it.
What's the first thing you remember struggling with on SQL Server? Your first memory of, "Dang, I just can't figure this out," and then you had a Eureka moment later when it was so much more clear?"
I asked folks on Twitter, and the answers were great, so I had to round 'em up here to share 'em with you:
It's not just you: it's hard for all of us to figure out where to go when we find a bug or want to add a feature. Here's a quick rundown: Azure Data Studio - open an issue in the Github repo. While you open an issue, Github helps by searching the existing issues as you're…
All of these are doable with scripts, tools, and/or elbow grease, mind you - they're just not as easy as they sound at first glance until you know about the existence of those scripts, tools, and/or free people waiting around with spare elbow grease. "Go through the log and find out who ran this query." "Apps sometimes…
Here are the 2018 blog posts you visited the most:
10. What's New in SQL Server 2019 CTP 2.1: Faster Functions - We're excited about a lot of stuff in 2019, but this is by far and away the winner.
If you like learning random tips & tricks, there's a great discussion going on in Reddit:
What are your game-changing discoveries in SQL?
Every now and then, you're going to need to run a query that takes a long time. You're going to want to make sure that it succeeds and that you can see the full output - even if your workstation disconnects - or maybe you want to check the status from home later.
You're going to be tempted to remote desktop directly into the SQL Server itself and run the query there.
1. Are backups and CHECKDB being done? Before I step out on the wire, I want to know if there's a safety net. If there's a recoverability risk, I don't stop here - I keep looking because the rest of the answers affect the safety net we're going to put in place. 2. How's the…
So you just built a brand new SQL Server, and before you go live, you wanna check to see if it's going to perform as well as your existing server.
The easy way: test your maintenance jobs
It's as easy as 1, 2, 3:
This week, we're sharing some of the Instant Replay videos from our training classes. First up is Drew Furgiuele talking about PowerShell functions and parameters:
https://vimeo.com/261640343
Pumpkin Spice
When I'm looking at someone's server, it's easy to tell the kind of care it's been under.
We've written a lot about servers that have gotten the wrong kind of care. You know, no backups, no checkdb, but someone managed to turn auto create stats off for every database, and enable affinity masking. That's not what I'm here to talk about today.
Long before the "full stack developer" phrase became fashionable, us early developers did exactly that. We didn't do any of these full time, mind you - full stack doesn't mean full time.
Here's a grid I use to explain the work involved in building and troubleshooting database apps:
In the course of your career, you're going to accumulate a folder of scripts to do various tasks. There's one really, really important lesson you need to learn as early as possible.
In a comment, include a link to the original source.
There's no Latin word for Robot
I'm all for automation, especially when it comes to the boring stuff. As awesome as the automation routines we have for that are, I still see people messing it up.
Right now, there's no Clippy/HAL mashup glaring at you, telling you that what you're doing is a bad idea.