Voice of the DBA

Author: way0utwest

  • Looking Forward for T-SQL Tuesday #100

    tsqltuesdayIt’s T-SQL Tuesday #100. Amazing. I can’t believe this has been going for so many years. I’m proud that I had the chance to host the main archive site at tsqltuesday.com and host a few topics.

    This month we return to the original founder, Adam Machanic, with the topic of looking forward 100 months. I wrote about predictions last week, so here’s a shot at a few more details.

    July 2026

    I’m approaching the big 60. It’s a year away, and I can remember joking with Allen White about how old he’s getting. In fact, it wasn’t too long ago that I had the chance to mourn that milestone with Grant Fritchey as well. Apparently my turn is coming, but that’s fine.

    Life is good and I still enjoy working with SQL Server. It’s been 35 years now that I’ve been on the platform and after a slow few years of few versions, things have taken off. As I write this, I’m working on CTP of v23. Microsoft tried to do away with version numbers, but there are still many of us that need to run our own SQL Server instance. We expect SQL Server 2026 to be released in a few months, and it’s looking good so far. I’m especially pleased that Microsoft has continued to produce separate versions of SQL Server for different platforms.

    Linux and Beyond

    A few years back we got a version of SQL Server on Linux. I remember being both pleased and surprised by the first demo I saw back in 2016. As I learned more about the process, it was a neat engineering challenge for the team, but once they conquered the underlying API mapping, the rest of the code based was roughly the same. This work allowed Microsoft to continue to expand their platforms, and today we have a small version of SQL Server Express on ARM processors, which can automatically sync data with our larger systems.

    Speaking of syncing…

    Replication Works

    I’m not sure how or why, but in 2021, Microsoft finally started to put some resources onto replication. I suspect they realized that many companies need more than just HA solutions for full databases. Customers need to move data around for other systems, to ensure MDM works, and gain compliance with the GDPR, UK, Japanese, and other legal frameworks. Customers also need to move subsets around for reporting, so replication got some love.

    It’s more robust, requiring DNS to register the publishers, distributors, and subscribers. We have custom schema changes that can move data, and the entire process actually has tooling in SSMS to help monitor the system.

    All that work with Linux helped, with better network discovery and reliability across all SQL Server versions. Parts of the system are built on the old Data Sync architecture, and more people are willing to use it since we don’t have to drop and rebuild replication for schema changes.

    Multiple Query Engines

    A little over a 100 months ago, we got the graph query engine in SQL Server 2017. It wasn’t that popular, but people used it and now we can use both Gremlin and Cypher.

    SQL Server also added MongoDB API support, as well as a streaming database option for the incredible levels of data ingest caused by the IoT device growth. These are add-ons, and at least with MongoDB, they’re free in all editions. Streaming requires enterprise, which makes sense. Smaller companies don’t really need that level of data ingest.

    Cloud First

    Almost everyone is thinking cloud first. Thankfully, Microsoft changed the pricing of Stretch Database, and allowed us to move data to the cloud or back again to meet our needs. This has been helpful as most companies use a hybrid system, and as they grow and stabilize their workloads, often want to bring some of their data back into their own data center.

    We’ve gotten more choices, as well. There are third party vendors, like Rackspace, that can run an Azure SQL Database or a CosmosDB instance. Microsoft licenses the system and provides third level technical support, but this has made all the difference in the world. Companies know they aren’t stuck with Microsoft for Azure SQL Database, so they’re more willing to give it a try.

    Closer to the End

    It’s been a great SQL Server ride for me. At this point I’ve been working with SQL Server for 40 years, and I’m getting close to the end of my career. I really enjoy the platform, and I’m still keeping busy with SQLServerCentral, Redgate, and a few clients, but I’m also taking more and more time off.

    Hopefully you’ve had a great career to this point, and you will continue to enjoy working with SQL Server, as I have.

  • Is Security Catching On?

    This is a good sign, as a poll shows people want security over convenience, especially younger people. Surprisingly this is also true for older people, who likely don’t trust much of our new technology. This is the first time that a majority of poll respondents haven’t been happy to have some easy password acceptable or the convenience of linked accounts. More and more people are embracing biometrics and using password managers with separate passwords for services, especially those that involve sensitive data. That’s a change for the better, since security is important if we are to continue to grow and enhance the use of digital services in our world.

    I think many of the issues with security are because of people near my age, the generation that has grown up as technology has. We’ve embraced and extended the very rudimentary systems that existed before Internet use and mobile devices became widespread. We also learned to build services in a way that gets them up and running without considering security from the beginning. Many of us grew up with computers that were either on or off, without any security implemented. We learned to network with completely open shares, and didn’t bother with access control. This is the same way many developers learned to build SQL Server applications using the sa account, not wanting to spend time learning the (basic) intricacies of SQL Server security.

    As we deal with an ever growing number of data breaches (over a thousand last year), it seems that many of the people working in technology, likely from my generation, still have not learned to build security early into an application. We add security later, after we’ve gotten a prototype or minimally viable product released. In many cases, we might never build security until we suffer some sort of incident. That’s the wrong time to start looking at limiting access.

    With the GDPR being enforced this spring, there will be plenty of pressure on companies to avoid being in the headlines for a data security issue. I’m hoping that customers will continue to put pressure on organizations to adopt better security measures.  Between customers and new legislation in various countries, I’d hope that more managers would understand that security is important and make it a priority for their staff. Most technical people want better security, even at the expense of a little inconvenience. These changing times might just allow us to get our wish.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.8MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Catch up on SQL in the City 2018–GDPR Edition

    The videos for our SQL in the City 2018 broadcast from last month are up on the Redgate channel in a playlist. If you missed anything or would like to rewatch something, you can do it.

    If you’ve got questions or comments, we’d love to hear from you.

  • Abolish Disjointed Time

    One of the more complex types of data to deal with is date data. We have dates, times, strange rules for when mathematical operations occur, and when they don’t. We have a period, which can be some combination of these, and that can include math rules that must be programmed consistently. Add to the issue of time zones where 3:00 isn’t 3:00 everywhere in the world, especially those strange half and quarter time offset zones, and it’s much more complex than seems necessary. There are no shortage of questions and articles at SQLServerCentral because this is a complex topic.

    I read recently that the European Parliment is considering getting rid of DST. Quite a few of the members think the practice isn’t useful and in a 384 to 153 vote, they decided to review whether or not they think this is a practice that should continue. There have been studies that show the change doesn’t help with power, and it’s certainly disruptive to everyone. I know it seems a percentage of people are always confused and either arrive early or late every year (or twice a year) when the clocks change. I know I’ve been late to work in the past on a Sunday when the clocks changed.

    I’m of the opinion that we should do away with DST. I get a double whammy every year the I work for a company in the UK and the US changes clocks at a different time. That means I get meetings that move for a few weeks, and just as I adjust to the new time, they move back. It’s a pain, and I’d just as soon do without it. There are also the adjustments to body clocks that likely slow our work and study habits, or at least mine, for a period of time. I’d just prefer that we stick to a single time schedule the entire year.

    From a data perspective, the adjustments can cause issues with reporting and tracking data. Having an hour essentially repeat itself can distort any aggregation over that time period. Likewise losing an hour, especially if we use left joins to ensure each time period has a value, can look funny. I know the data issues aren’t likely a big deal, after all, how much data does your company gather in the middle of Saturday night a couple times a year? Most reports probably don’t bother to account for the discrepancies, and there don’t seem to have been any issues I’ve seen from organizations. It’s annoying to me as a data person, but it’s probably not a significant issue.

    Ultimately I think DST is just a little silly in this modern world, where specific times, especially daylight time, seems to be less of an issue. I work when I need to, take time off when I can, and it seems more and more companies do the same thing. Whether I go to work in the light or dark, the days are shorter in the winter.

    Steve Jones