Author: way0utwest

  • Defining FKs in CREATE TABLE–#SQLNewBlogger

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

    One of the important things that a database developer can do is to define Foreign Keys (FK) at table creation. This is a good time to do this as the referential integrity gets setup before any data is added and this can prevent issues later.

    This post shows the syntax for defining the FKs and adding them to your tables immediately.

    Build the Reference

    The first step is to ensure you have a table with a Primary Key (PK) that will be referenced. Let’s do that first. I’ve been looking to provide a database of SQL Server Builds, so let’s start with a table of versions.

    CREATE TABLE SQLServerVersion
    ( SQLServerVersionKey INT IDENTITY(1,1)
    , VersionName VARCHAR(200)
    , CONSTRAINT SQLServerVersionPK PRIMARY KEY (SQLServerVersionKey)
    )
    GO

    The PK in this table is what is referenced in the next table. This is required as a FK must refer to a PK in another table.

    Add the Reference

    When you build a child table, you may write the code like this:

    CREATE TABLE [dbo].[SQLServerBuilds]
    (
    [BuildKey] [int] NOT NULL IDENTITY(1, 1),
    [BuildNumber] [varchar] (30)  NULL,
    [BuildDescription] [varchar] (100)  NULL,
    [BuildKBArticleNumber] [varchar] (50) NULL,
    [BuildKBArticleURL] [varchar] (1000)  NULL,
    [SQLServerVersionKey] [int]  NULL
    ) ON [PRIMARY]
    GO

    However, in this case, you’ve ignored the FK that might link this table to the versions table. This means that a value could be entered in this table that doesn’t exist in the SQLServerVersion table.

    You might think this won’t happen with your application, but thousands, maybe millions, of developers have felt the same way. And they have junk data in their databases because of this.

    If there is a strong relationship, add the FK.

    Here’s how we do that in the CREATE TABLE statement. I’ll add a comma at the end and include a CONSTRAINT clause. I add the name and then the FOREIGN KEY keywords. Next I include the column from this table that is the FK with the References and the other table and column.

    CREATE TABLE dbo.SQLServerBuild
    (
         BuildKey INT NOT NULL IDENTITY(1, 1) ,
         BuildNumber VARCHAR(30) NULL ,
         BuildDescription VARCHAR(100) NULL ,
         BuildKBArticleNumber VARCHAR(50) NULL ,
         BuildKBArticleURL VARCHAR(1000) NULL ,
         SQLServerVersionKey INT NULL ,
         CONSTRAINT SQLServerBuild_Version_FK
             FOREIGN KEY (SQLServerVersionKey)
             REFERENCES dbo.SQLServerVersion (SQLServerVersionKey)
    ) ON [PRIMARY];
    GO

    This is the structure I tend to use, though sometimes I’ll move the CONSTRAINT clause directly below the actual column. This lets me see right away this is related to that column.

    I also avoid using this inline in the column as I can’t specify the constraint name, which I always want to do.

    SQLNewBlogger

    This is a core skill that database developers needed. If you know the syntax, this post would take about 10  minutes to structure and write. If not, maybe it’s 10 more to learn a bit.. Write your own and show you understand the design concepts.

    Reference

    Creating Foreign Key Relationships – https://docs.microsoft.com/en-us/sql/relational-databases/tables/create-foreign-key-relationships?view=sql-server-2017

  • Would You Move to Linux for Price?

    Running software on Linux is supposed to be cheaper than Windows. After all, you don’t need to pay for an OS license, right? I’m not sure I think the price of the OS is a determining factor, since it’s a relatively low amount compared to the cost of the database license. I’m sure some of your feel differently, and I’d be happy to listen to your argument as to why the Linux is better on price.

    In any case, Microsoft is looking to push the Linux version of SQL Server. For a limited time (until June 30, 2018), you can get 30% off the cost of a SQL Server license. They’ve also gotten the cost of SUSE Enterprise Server down to $0 for a year if you are a qualified customer. This does require an annual subscription, which I assume means Software Assurance. There’s not a lot of information available on their page, and I assume you’d need to call Microsoft and go through the sales process.

    It’s an interesting offer. I wonder if this would really make a difference for some of you. For the purpose of a discussion, let’s say you run an older version of SQL Server on Windows, like SQL 2000 or 2005. You want to upgrade, but your boss has been worried about costs. Now you see a 30% savings on Linux. Do you consider moving to a Linux OS instead of Windows? Let’s assume you have some Linux resources inside the company, and so there isn’t a large learning curve. Does 30% make enough of a difference do change the underlying platform? After all, for the post part, SQL Server is SQL Server.

    What if you are a Linux shop already, and you have Oracle or DB2 in house. You’re looking to move some software to a new system, or maybe develop new applications and SQL Server is being considered for cost savings. You’ve avoided it because it has required Windows in the past. Do you now consider SQL Server a more viable candidate as a relational database inside your environment?

    Would you move to Linux for a better price?

    Steve Jones

    The Voice of the DBA Podcast

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

  • Confusing Networking Behavior

    The other day I got on a Skype for Business call and I struggled to hear the other people. I looked at the interface, and saw red where the network connection was represented. Since I was communicating with the UK, and I sometimes see issues, I assumed this was our office over there.

    Then it happened the next day. I decided to assume it was my issue, and I ran a speed test.

    2018-04-19 10_00_00-Speedtest by Ookla - The Global Broadband Speed Test

    That’s not great, but that looks OK. I’d think this was enough bandwidth for a video call. No one else was in the house, so there shouldn’t be contention. After contacting both Redgate’s IT group and my provider, I ran a ping test.

    2018-04-19 10_02_00-cmd - ping  _t redgate.slack.com

    If you know anything about networking, you know this is no bueno. The periodic long times will cause stuttering and problems with real time communications. A short, 4 ping test might not show this, but over time, you can see things repeating.

    In this case, it seems something is wrong with my connection.

    However

    That’s not the issue. I called my provider, and they didn’t see issues from their end. We restarted the router (hard start) and things didn’t see to improve. They escalated, which is a callback, so I went on with my day.

    This was bothering me and I had more calls, so I decided to restart my machine. After the system came up, I started shutting services down. No Spotify, no TweetDuck, nothing with network access.

    In the meantime a call started, which had stuttering and issues, as you might expect if regularly there was a 1-3s delay for packets. In this case, I finally got to my Crashplan backup process. This was backing up files, which is something that has been happening for a few years. However, as soon as I shut this down, my video/audio issues stopped. In fact,

    2018-04-23 11_41_29-cmd

    That’s more what I have been experiencing for years.

    Since then I’ve restarted that process a few times, just to see, but issues haven’t returned. In hindsight I should have tried video from another machine and made sure this was a networking issue and not a “this machine” issue.

    I’ve been good at troubleshooting in my career, but this is one of this times that I didn’t really do a good job of looking at the trees and not the forest. I made assumptions and experienced issues for a few days that were unnecessary.

    A good reminder and lesson for me.

  • Auto-Deleting Data

    Email has been a part of my life for well over nearly thirty years. It’s kind of amazing to think of a time back in high school when there weren’t electronic communications. That seems foreign now, as we don’t have to send physical objects or converse with voice to communicate. The world of communications have changed dramatically.

    These days email is still a preferred method of communication for many people. Even if we use sites like Facebook, NextDoor, or SQLServerCentral to communicate with others, we often get notifications of changes through email. If you’re like me, many of you might keep far too many emails in your mailbox, rarely removing unnecessary ones. In the era where we measure storage in dozens or hundreds of GB, or even in TB, do we bother to even manage text communications?

    Some firms do require this, often for legal reasons. With the GDPR, I wouldn’t be surprised to see more organizations starting to set retention policies that ensure that communications don’t live forever. There are some systems that do this now, but the practice isn’t ubiquitous, but maybe it will be soon. Google is redesigning Gmail, which will include Confidential Mode. Not only will there be limits on these emails, but one of the more interesting is the ability to expire an email and have it automatically deleted.

    I don’t love the idea of having communications disappearing, but that might be because of the way I’ve grown up. I don’t like using Snapchat with my kids, because I don’t want pictures I take to disappear. However, younger generations don’t feel this way. As I wonder why I try to hold onto old communications and records, I start to wonder if the idea of expiring data is something that we should be embracing as data professionals. Do we really need sales records from a decade ago? Are recordings of web traffic valuable from the early days of SQLServerCentral? Is there really any point to holding onto much of the data we generate?

    I know that there are corporations that hold onto decades of paper records. I worked at one that had nearly a 100 years of old records, most of which might never be examined again. Likely plenty of them aren’t even legible or useful at this point. They’re being stored for, well, I’m not sure why. I’m sure there are plenty of writers that might come up with a detective story that requires old paper records, but I’m not sure there’s practical use for this data.

    I expect that we’ll start to see organizations changing their record retention policies as we look to avoid more liability and risk from data breaches. Every old record, every piece of PII data that we no longer use probably needs to go. Even records for existing customers might need to be removed. I don’t necessarily need to ever access the record of my first Amazon order from 1998. I’m really sure that Amazon having liability for holding my old address, which potentially could be used to validate identity, is a bad idea for both them and me.

    Steve Jones

    The Voice of the DBA Podcast

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