A Broken Streak

Posted on July 30, 2020 by way0utwest

SQL Saturday #1 was in Orlando, as the first actual event that has gotten us to nearly 1000 in just over a decade. I didn’t go to the first one, but I did go to SQL Saturday #8 and many more since that time. I’ve been luck to get back to Orlando a few times, and I look forward to more in the future.

Andy Warren announced that this year’s SQL Saturday in Orlando is cancelled. This breaks the longest streak so far, and I’m sad to see that. I wasn’t likely to go to Orlando this year, though this city is always on my list. I was hoping the event would take place in some form, but I understand the desire to step back and examine how to move forward.

A virtual SQL Saturday isn’t quite the same for me. I’ve presented at one, and submitted to a couple more to support them, but I don’t love this format, and I think it becomes hard to make it a special event for your city. I know a few more are planned for 2020, and I hope someone runs a SQL Saturday with only local speakers for that area. That might make it feel like a local event.

Since the pandemic hit, and since SQL Saturday #950 in Victoria, I’m not sure anyone has held a live event. I’m not sure when the next live SQL Saturday will be, but I’m hoping that it happens in 2021 sometime. I don’t think anyone can plan for this year, but I am hopeful we will find a way to get back to some live interaction next year.

We have until 14 Mar, 2021 to avoid losing a whole year of SQL Saturdays and breaking a streak of having them every year since 2007. I’m confident that if it’s safe, someone will organize and run a SQL Saturday as soon as they can. I’m also sure it will be well attended as I’m guessing many of you are looking forward to a live event as much as I am. I just hope I get the chance to speak, because I will certainly be ready for a live audience.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Posted in Editorial | Tagged , | Comments Off on A Broken Streak

Daily Coping 30 Jul 2020

Posted on July 30, 2020 by way0utwest

I’ve started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here.

Today’s tip is to catch yourself overreacting and take a breath.

I didn’t remember to breathe recently, but fortunately my wife helped me.

Our sink got clogged up recently. I cooked some breakfast, and afterwards, I threw out a few pieces of old chicken that were in the fridge as I started me cleanup. The sink clogged, and I couldn’t get it to work. I took a break, then ran to the store for a snake, which I tried to use. I ended up taking apart the lower U joint and getting all 20ft down into the pipe, but I still looking at this:

20200715_173004_HDR (1)

I worked on this for a few hours, doing a little work when I needed a break, but at 5pm, I couldn’t figure anything out. I was frustrated, upset, stressed as I had some deadlines at work, I didn’t get to exercise, and I still didn’t have a working sink for dinner.

My wife reminded me to breathe, to relax, and forget about it. She called a plumber for the next day, told the kids to find leftovers, and took me out for dinner and a drink to relax. It was good to just stop worrying about a minor thing and just move on with life.

Posted in Blog | Tagged , , | Comments Off on Daily Coping 30 Jul 2020

Adding a FK to a Table–#SQLNewblogger

Posted on July 29, 2020 by way0utwest

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

One thing that helps ensure your data is intact and doesn’t get out of synch in a relational database is a foreign key. You ought to have these as a part of your design, ensuring that a linkage between a parent and child cannot be broken.

This post looks at adding a FK to an existing table. I’ve written about how to do this in the CREATE TABLE statement in another post.

I have two tables set up: Contacts and Status. Both of these have a StatusID column in them. The Status table contains the lookup values, and these are stored in the child table, Contacts.

To add the foreign key, I add a constraint with the ALTER TABLE ADD CONSTRAINT syntax. After this, I use FOREIGN KEY to list the column(s) and then the REFERENCES phrase to point out the parent table and column.

The example is shown here:

ALTER TABLE dbo.Contacts
   ADD CONSTRAINT FK_Contacts_Status_StatusID FOREIGN KEY (StatusID)
      REFERENCES dbo.Status (Statusid)
;

This will give me  a FK that enforces the values in Contacts as existing in Status.

SQLNewBlogger

I had to do this recently and decided to quickly write this up as I had to look up the syntax to be sure I remembered it correctly. Then it took me about 5 minutes to produce this.

It took me almost as long to see if I’d already written about altering a table with a FK.

Do this for your career, and to show interviewers that you know how to handle common data referential integrity tasks.

Posted in Blog | Tagged , , | Comments Off on Adding a FK to a Table–#SQLNewblogger

The Old Way or the New Way

Posted on July 29, 2020 by way0utwest

Many of us are employed because of our talent and experience. We get things done and our organization values what we do. We got this position because we did something well, as a DBA, developer, manager, or some other role.

It’s natural that we feel confidence in our abilities and knowledge. However, that shouldn’t prevent us from learning new skills, techniques, and patterns for getting work done. As much as many of us want to feel we regularly learn in technology, I often find that customers, clients, and friend struggle to change their habits.

Why is this? There is a good post on the topic that looks at why people want to use the old way. It’s from the perspective of the developer that shows something to a client, but I think this applies to many parts of our world. Making change has an effort, and the effort needs to have a high enough return to be worth making a change.

In terms of development, do we change our efforts when something is slightly better? Perhaps, especially if there security or resource changes could be high for our final deployment. What about if the changes are most nebulous, like slightly less technical debt? Or if there is a chance for more future flexibility in the design? The benefits we get back are sometimes hard to measure.

The changes also need to be considered for a team. A change for my coding habits might be low with little disruption to my workflow, but the change for a team of 10 is a multiple of the effort. We all have to make a change, and that can disrupt an entire sprint, or a series of sprints if our focus and rework increase as everyone tries to adapt.

My general rule of thumb is that some change has to be at least 20% better in some way. It has to make a fundamental difference to be worth the effort. This is one reason I never moved from Google to Bing. Bing works fine, but it’s not 20% better. I’m not sure it’s 1% better. It’s different, and that has a high cost to me to change.

Moving to new ways of working can be good, but the movement needs to be careful and slow, especially in a team environment. However, we also need to learn to move more when there are enough benefits. We sometimes forget that last part.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Posted in Editorial | Tagged | Comments Off on The Old Way or the New Way