Voice of the DBA

Tag: T-SQL Tuesday

  • The Conference of the Year–T-SQL Tuesday #153

    tsqltuesdayIt’s the second Tuesday of the month and it’s time for T-SQL Tuesday. This one is hosted at my request by a good friend, Kevin Kline. Kevin has been a large part of the #sqlfamily as a speaker, teacher, educator, friend, and driving force for PASS and the annual Summit conference.

    This invitation is asking about a conference or event that changed your life, that created an opportunity, or just changed your life. Career, other otherwise. It’s a great topic, and it’s one reason that I am running SQL Saturday. Events and interactions with others can change your life. It did for me, and for many others.

    1999

    This year always stands out as a reminder of Prince (RIP). However, it was also the first year I lived in Denver. I moved out with my wife and two kids to work at a financial services firm. That summer I saw an advertisement for a new professional group, the Professional Association for SQL Server. They were having a conference that October in Chicago. I asked my boss to go, they agreed, and I made arrangements.

    Two things stand out to me. First, my wife, sister-in-law, and toddler son came. We went to the last baseball game of the year at Comisky Park. My wife and SIL  also smoked cigars with me in the hotel bar. A memorable fun trip for me.

    The second thing that stands out is that I met Kalen Delaney there. I’d read her Inside SQL Server book and watched her talk. Afterwards I went up to the stage and asked a question and shook her hand. An exciting moment for a young data professional at the time, and one that spurred greater interest in learning more about SQL Server and becoming a better DBA. I’ve also been honored to know Kalen and meet her at many events around the world since.

    That event kick started me from being just a DBA to being someone that wanted to be involved with the community, that believed I could speak in front of people and teach them things, and I could help my career by attending other events.

    Conferences and Career

    Most years I attend 10-20 conferences and speak at them. I may attend a few others and not speak, and I usually have a few internal or Redgate run events. I’ve very lucky, and I enjoy getting to visit interesting places in the world as a part of my job.

    While I pick up technical bits and might get an idea for how to solve a problem in code, the most valuable parts of conferences are talking with other people and networking. Yes, networking, which is really just shaking a hand and answering a question. Or shaking a hand and asking a question. Or even commiserating with someone next to me about how some technology doesn’t work. Sometimes those last conversations are the most memorable and enjoyable.

    This networking is incredible and I’m amazed how I hear about different opportunities. Even before I ran SQL Server Central, talking to people at events drove my career forward.

    Whether you go to a user group meeting, a local SQL Saturday, or a larger paid conference like the PASS Data Community Summit or SQL Bits, if you make an effort to chat with people, interact, and take notes, I think you’ll find it as invaluable to your technology career as I have.

    Getting Involved

    The last thing I’d note is that I run SQL Saturday as an independent, US charitable 501.c.3 corporation, independent of Redgate. I’ve found user groups to be great, but hard to manage every month. When Brian, Andy, and I set up SQL Saturday, we did so to bring local conferences to people whose employers might not pay to send them to Ignite, the PASS Summit, or other expensive conferences.

    I would love to see more SQL Saturdays in more places in the US. It’s not that hard to run one, and you don’t even have to speak in front of a crowd. If you’re interested, ping me at admin@sqlsaturday.com.

  • T-SQL Tuesday #152–It Depends

    tsqltuesdayA great invitation this month from Deborah Melkin. I thought this was very apt, as I use this phrase often. Many of us do.

    This was a tougher post to write because, well, too many choices. However, I sat down to try and give an example of where this comes into play for me.

    Everyone should write a post, or a few posts, on this topic. Your decision making and reasoning are important things to share with others.

    The Devil is in the Details

    I deal with quite a few proof of concepts and questions about altering database development practices. One of the questions I’m often asked is how does a particular group get started with automating their database deployments.

    It depends.

    That’s really the answer, and I have to start to ask them questions about their pains. What is the driver for change? What things don’t work well right now? The answers to what doesn’t work well will drive how we move forward.

    Is it failed deployments? If so, then is this bad code? Let’s test more. If it’s people not always running all the scripts, or the right scripts, then we need a test environment where we actually run scripts to see if they work.

    Do you lose track of what changes developers have made? Let’s make sure we have version control as a funnel to capture all changes, and from there we can look at manual or automated deployments of what’s changed.

    Are you struggling to get code that meets the requirements? Again, testing can help, but maybe you need to structure better communications between developers and business customers, and make small changes that your customers can actually see and test.

    If you can’t keep up with requests from developers, then maybe this isn’t about database development and this is more of a staffing issue.

    The devil is in the details, and to make a successful leap to a smooth DevOps process for database development, we want to adapt to your environment. Let’s address the pain, and minimize the changes we need to make.

    There isn’t a once size fits all. This is a set of tools and principles we want to use, but in a way that works best for your situation.

  • T-SQL Tuesday #151 Coding Standards

    This month the T-SQL Tuesday blog party is hosted by my good friend, Mala. This is her fourth time hosting and she has a good topic this time. While I love her hosting, and a few others, I would like to see more people participate and take a month on their technology of choice.

    You can submit to host by contacting me on Twitter and reading the host page.

    Coding Standards

    I am a big fan of standards, both for coding and naming, when building software. I feel that having some standards help share information among staff. Since staff might come and go on a project, the less friction that we have, the better off we are.

    With that being said, the main standard for me is that the team has a standard. Preferably the organization has a standard, but we want to ensure that everyone follows a similar style of coding. This includes naming and style.

    For example, if we want plural names for all entities, let’s stick to that. I think singular makes more sense, and despite my habit of years of plural, I have been working to change. If my team wanted to go one way or the other, I’d just work with them.

    The same thing goes for commas. I like commas before a column list, but if the team prefers after, then that’s OK. I can adapt. Especially with a tool like SQL Prompt that let’s me easily reformat to another style.

    The other advantage of coding standards, apart from transferring information, is that we can use templates and snippets of code as a way to speed up coding. We can even write or use code generators to ensure that we build the code that everyone understands.

    A Few Specifics

    For me, these are things I’d set up if there were no standards. I’d be welcome to debate on them and be willing to change. These are for SQL. For other languages, there would be similar choices based on the language.

    1. commas before column list columns
    2. start column list on a new line
    3. FROM, WHERE, ORDER, GROUP, HAVING all indented 1 space or tab from left
    4. I prefer spaces, but only lightly.
    5. align all clauses in WHERE on separate lines
    6. entities use singular names
    7. primary keys are named <tablename>PK
    8. if surrogate keys, use <tablename>ID as the column header
    9. FK constraints use FK_<source>_<destination>_<column1>_<column2>
    10. ALL indexes named as CDX_<table>_<column> for clustered or NDX_<table>_<column> for non clustered. CCX or NCX for columnstore.
    11. FK column in the child table uses the same name as the PK column in the parent.

    There are more, but this is a quick list. The important thing is to have standards.

  • 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.