Voice of the DBA

Tag: T-SQL Tuesday

  • My First Technical Job: T-SQL Tuesday #150

    It’s that time of the month again for a T-SQL Tuesday blog party. This month is hosted by Kenneth Fisher, who has hosted a few times in the past. I like this topic, and it’s a good one for me to think back to my earlier career.

    I am very curious to see what others might write.

    It’s Who You Know

    Perhaps one of the things that I learned early and didn’t believe is that networking, connections, and who you know matter more than what you know. The what is certainly important and can help you succeed in day to day work, but for landing jobs, networking is king.

    I actually had my first technical job as a computer person in high school. I had gotten interested in computers and owned a Commodore Vic-20 and 512, and later an Apple II compatible. My Mom wasn’t sure about spending all the money, but she did and I spent hours digging into how things worked.

    My neighbor owned a construction business, laying water and sewer pipe. Later I worked in that side of the business, but the spring of my junior year he was struggling to implement a new estimation and inventory program on his first PC. His secretary was a nice lady, but in her 50s and in the early 80s, computers were completely foreign. He chatted to my Mom about things and she said I might be able to help.

    This was the first time I was thrown into a situation where I didn’t know a lot, but it wasn’t the last. In fact, these same skills were useful as a consultant:

    • reading manuals
    • grasping the relation between quickly written words after the fact and software
    • experimenting without causing breakage
    • making backups and learning to restore
    • explaining how software worked or needed configuration in layman’s terms
    • perseverance when you are struggling
    • projecting confidence when you don’t feel you have much

    These were the things I had to do over a few weeks as I learned how the software worked, installed it (a few times), set things up, and worked with the secretary and a few foreman to help configure things the way they wanted them. I also had to train them to use the software to enter data.

    Outside of school, this was my first technical job. I think I got paid $10 or $12 an hour at the time when most jobs were $3.35/hr at minimum wage. No big earnings, but I probably made enough to buy a few $50 video games or software games.

    The rest, as they say, is history.

    BTW, laying water pipe a couple summers later taught me a lot as well.

  • T-SQL Tuesday #149–Advice about T-SQL to a Younger Me

    It’s that time of the month again, when we have the T-SQL Tuesday blog party. This month we have a new host, Camilia Henrique with an invitation on advice you would give to your younger self, but in the area of T-SQL. That’s a good one, and it focuses on a technical skill that many data professionals need.

    Participating in T-SQL Tuesday is a good way to practice your writing, your skills, and show your thoughts on some aspect of your job. Even if you miss the party one month, feel free to write a post later and link it to the main post on the T-SQL Tuesday site.

    Practice, Practice, Practice

    I learned SQL first as someone working with dBase, FoxPro, and Clipper. I moved to SQL Server and T-SQL later, with a basic grounding on how to query for simple sets of data, but I quickly learned performance can matter a lot.

    As I’ve tried to keep up with the language, one of the things that has struck me is that T-SQL can be complex to structure because it’s relatively simple with few keywords. You can unintentionally create cross joins or row-by-row (RBAR) structures that perform poorly and waste resources on your system.

    I’ve found that practicing with programming exercises and solving problems to be the best way to improve my skills. I don’t do it enough these days, and when I answer questions on SQLServerCentral, invariably one of the experts there will post a solution that performs better and I learn something new.

    If I were talking to myself, I’d say to look more deeply into APPLY and the OVER() clause right now. Make sure you understand tally tables and their uses, and work through exercises like the Advent of Code, Exorcism, Project Euler, or something similar. Heck, just answer questions in a forum for yourself, with your own solution.

    Learn how to create queries that can efficiently gather together, filter, and aggregate your data in ways that are helpful for clients without taxing server hardware. In the era of cloud computing and pay for data moved or data processed somehow, this is an invaluable skill.

  • T-SQL Tuesday #148–User Group Advice

    tsqltuesdayThis month the T-SQL Tuesday invitation is from Rie Merritt, and it’s one that means a lot to me. I don’t actually run a user group, but I think community is important. It’s a big part of my job and my life.

    Rie asked me if she could host this month because she had a specific topic. If you’d like to host a T-SQL Tuesday, all you need is a blog and participation in another month by writing a post. You could even write a post today for T-SQL Tuesday #1.

    If you’re interested, contact me.

    Advice for User Groups

    As I mentioned, I don’t run a group. In fact, I never have, but I have run events, attended lots of meetings, and I do speak at quite a few.

    The pandemic has been hard on many groups, and a blessing to others. While I don’t like the virtual meetings, I understand how and why they work for some groups and not for others.

    My big advice for organizers is twofold, and I’ll write a couple paragraphs about each.

    Serve Your Community

    My main advice is that your work with groups or events, whether leader, speaker, or something else, you ought to make sure you are serving your community. What is best for them, or what do they want?

    Sometimes I find leaders doing what’s best for them, without knowing what the community might prefer. If you want virtual meetings for your own personal reasons, whatever they are,  make sure a large portion of your attendees and speakers agree. Same for in-person meetings. If your area wants to stay online, understand that.

    This isn’t to say that you can’t experiment, and that you might make decisions on days/times/etc. More it’s advice to think about what helps people as we come out of this pandemic.

    Go Slow

    I’ve seen a lot of groups struggle over time to run a monthly meeting and find speakers. Speakers are easier online, but it’s still work.

    My advice is that you can consider doing something less than monthly, especially if you move to hybrid or in-person. A quarterly or every-other-month pace might suit you (and others better).

    Also think about adding in some lunch meetings, perhaps just discussion ones without a presentation. Bond, be social, just talk, vent, and share what we love about data and technology.

    Don’t kill yourself. I’d prefer you enjoy running a group for 3 years than burning out after 6 months.

  • T-SQL Tuesday #147 Wrap-Up

    I was the host this month for T-SQL Tuesday #147 and here is a look at the people who blogged (that I know about). If I’ve missed anyone, let me know.

    Rob Farley wrote about updates, not only with version upgrades, but also CUs and the need for automated testing.

    Deepthi Goguri talks about her first job and the requirement to move off SQL Server 2000. This was after her schooling was on SQL Server 2012. I like the emphasis on fear as a reason not to change, and the use of tools to find potential problems that could occur during the upgrade.

    Kevin Chant writes that he uses upgrade events as chances to improve the way a system works. He also uses the Data Migration Assistant to move, but do so carefully. Don’t jump across too many versions.

    Damien Jones asks us if we can avoid upgrades in the cloud. That’s an interesting perspective, and one I don’t see often. It is legitimate, as every time something changes, we need to test, and if there are issues, what do we do? Avoiding change is something that I find important in the short term but highly detrimental in the long term.

    Greg Moore writes about the challenges of convincing a client to upgrade.

    Glenn Berry gives us a way to make a case for upgrades, working against those that don’t want to change, and some thoughts on related tech changes that might help you decide to upgrade.

    Marcin Gminski talks about https://sqlwatch.io/blog/t-sql-tuesday-147-sql-server-upgrade-strategies/

    Alex Stuart notes that if it isn’t broken, why fix it? Don’t upgrade for no reason, but there are some reasons to upgrade and Alex lists them.

    Reitse Eskens gives us a basic process to follow when upgrading. These aren’t detailed steps, but these are the things I look at when upgrading.

    Gethyn Ellis talks about why we wait to upgrade and why we might rethink that.

    The first upgrade, from Todd Kleinhans, looks at the problems he had an how we got past an Access to SQL Server upgrade. I’ve been in this exact situation, back in the early 90s. It was a mess and very stressful, but I learned a few things. Including to avoid Access for years.

    Lastly, but not least, Martin Catherall provides some general thoughts on how he would approach an upgrade, with some tool suggestions to help.