Voice of the DBA

Tag: database design

  • Defining Foreign Keys at Table Create Time

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

    How many of you can define a foreign key when you create the table? Probably a few of you, but I bet most of you are like me and don’t necessarily know the syntax. I have often defined these later, which is fine. As long as they get defined.

    However I knew I needed a specific key when I was creating a table and couldn’t remember the syntax, so I had to search and learn how. I used Google and saw a few links from MSDN, but those tend to be overly documentation heavy. One of the links was to SQL Authority, run by Pinal Dave. He does a great job of simplifying things (and he’s a friend), so I followed that link. I could see the syntax and tested it in minutes.

    It’s easy to create a Primary Key in CREATE TABLE, and I wrote about that for one of my first SQLNewBlogger posts. The Foreign Key is similar, but not quite as simple.

    Imagine that I have a parent table:

    CREATE TABLE orders
  (
    orderid INT IDENTITY(1, 1) CONSTRAINT Orders_PK PRIMARY KEY ( orderid )
  , orderdate DATETIME
  , complete BIT
  );
GO

    I now want to create a child table and link the orderid in the child to the parent. I can do it like this:

    CREATE TABLE OrderLines
  (
    orderlineid INT
      IDENTITY(1, 1) CONSTRAINT OrderLines_PK PRIMARY KEY ( orderlineid )
  , orderid INT
      CONSTRAINT orderlines_order_fk FOREIGN KEY REFERENCES orders ( orderid )
  , qty INT
  );
GO

    Note that I define a constraint inline, just as I did for the parent. However I note this one is an FK and it "references" another table. In this case, I list the Orders table and put the columns in parenthesis.

    Quick, easy, build your FKs inline when you know about them in advance.

    SQLNewBlogger

    While trying to remember how to create an FK, I ran a search and chose the reference below to start. A matter of seconds had me seeing the syntax and writing the code.

    Putting this together was less than ten minutes.

    References

    Creating Primary Key and Foreign Key Constraints – http://blog.sqlauthority.com/2008/09/08/sql-server-%E2%80%93-2008-creating-primary-key-foreign-key-and-default-constraint/

  • Microservices for Databases

    I ran into a talented developer last year that was talking about microservices. It’s an interesting concept, one the Netflix has adopted with success. I was excited about the possibilities of using microservices until this guy said that everything could be a microservice and the day of the RDBMS was over.

    That was silly, and I’ll admit I struggled to remain polite in the discussion. Eventually I had to walk away because the idea of no RDBMS for any application is a ludicrous as the concept of using an RDBMS for every single system dealing with data. It’s frustrating to talk with someone that views our industry as too black and white. There are many ways to solve any problem and many problems can be handled by a variety of techniques.

    However I am intrigued by microservices. It’s an area that I want to continue to research, as I suspect that the idea of small, loosely coupled applications, working in a service-oriented architecture, is a great way to scale systems.

    From scratch.

    I’m not sure that many of the monolithic, large applications we have in banking, in retail, in supply chain, in a variety of industries are worth rewriting to use SOA concepts. The return just isn’t there, as many of these systems can be served with bigger, faster hardware as they upgrade.

    Microservices are interesting, and I suspect we’ll see more of them in the future. I also think that SOA, using messaging services like Service Broker, are a very robust way to build applications. I hope that more developers out there learn about SOA and find ways to start building system that can work well together, but aren’t so highly dependent that changes are difficult or stressful on everyone.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Microservices and Databases

    I ran across a post on microservices recently and was intrigued. I always like the idea of loosely coupled, independent items in software. However the idea of microservices causes issues with databases. Here’s the section in the piece by Netflix: Create a separate data store for each microservice.

    I tend to think of microservices is very small, tightly bound components of software. If that’s the case, how can I separate each item in a database? Do I want dozens of databases?

    I got in an argument with a developer a few months ago about this. The developer was sure that having separate databases (or stores) for each component wasn’t an issue. For things like banking and similar transfers, I’m not sure a microservice can be separated safely and still ensure integrity.

    This is a tough concept for architecture, and I need to read more and understand how this could work in practice. I suspect that in places where things could be separate, you could easily use schemas in a database to separate out microservices from each other. If each service includes its own connection information, then using schemas would work and still allow for scale out to other databases if needed.

    This is an area that certainly fits larger scale applications like Netflix and Spotify, but for many of us, our applications seem to be more tightly tied together.

    Or are they?

    Microservices are much like Service-Oriented Architecture (SOA), which I think fits many applications. I’m not sure how similar the concepts are, but this is certainly an area I’d like to learn more about.

  • Are There That Many GUIDs?

    This editorial was originally published on Oct 12, 2010. It is being re-run as Steve is away on vacation.

    Do a lot of people actually use GUIDs as Primary Keys? I haven’t used them much, and I would have thought that more people chose identity keys. It seems that most of the demos and examples I see from bloggers and speakers are constantly using identities.

    However an informal survey from Peter Bromberg showed that four times as many people actually had GUIDs as their primary keys. The blog actually says that GUIDs are not a good choice, but I’m not sure I agree with that. You can use sequential GUIDs, and you can avoid making them the clustered key, so I think they can work as well as anything.

    There’s nothing inherently wrong with GUIDs, and they should be unique across all of your rows. There have been some reported cases of duplicates, but for most practical purposes, especially in database work, you ought to be able to count on a GUID as unique. They even have the nice capability of being generated by clients, removing the need for an extra round trip when a client needs to insert multiple rows.

    I typically don’t use them because they’re long, hard to remember and type, and hard to view on the screen. I can’t easily compare rows in multiple tables, and it’s easier for me to work with integers.  I don’t recommend them, but if you are going to use them, be sure you understand the pros and cons, and use them appropriately.