Voice of the DBA

Author: way0utwest

  • Off to the Center of the Universe

    “New York City…center of the universe..” – Rent

    I’m off to New York this morning for the start of the 2012 SQL in the City US Tour. It kicks off tomorrow in New York City.

    As this posts, I’ve just dropped my son off at school early for a Future Business Leaders of America field trip as I head off on a field trip of my own. This is the start of a few busy weeks as I deliver presentations in 5 cities in two weeks.

    I’ve got a group with me as well. A number of talented developers and business people from Red Gate software, along with my co-worker Grant Fritchey (b | t) will be at all the events. We have some special guest speakers at each stop as well from the local areas and I’m hoping we deliver some great talks that you enjoy.

    We had a great time this past July in London and I’m looking forward to these events over the next two weeks.

    I don’t love the travel, and I’m popping in and out of home the next two weeks between some of the stops. However I love my family and my bed, and the chance to get home for a day is worth a little extra travel.

    New York is an amazing city, and I love visiting it. I’m hoping to get into the city and checked in by 4pm at the latest. Then I’ll head over the Central Park for a run. If you want to join me, I’ll be coming up 7th to the park, hopefully by 4:15 at the latest, but watch Twitter.

    Red Gate puts on a great event, and I look forward to seeing some of you in New York, or at any of the other cities on the tour.

    If you wonder where the lyrics at the top come from, watch this:

  • Pair Programming

    pair programming with cat
    I could probably handle some pair programming with this little one.

    I’ve never pair programmed, but I’m not sure I’d like it. As much as I like collaborating, I prefer alone time to work on problems, or think things through and experiment a bit on my own. I prefer brainstorming and discussion sessions to be limited in nature, with the chance to then go work on my own pieces along.

    However pair programming has been touted as a way to improve software quality by many people. It’s not as popular as some other methodologies, but it still exists out there. I ran across a programmer’s reflections on nine months of pair programming that made for a thought provoking read. He looks back at the experience and lists some pros and cons. Better code, more productivity, and lots of knowledge transfer were some of the positives, and would lead many managers to try and push developers into working in pairs.

    However there were downsides. As someone that speaks regularly, I think that the strain on my vocal chords would be hard if I had to speak constantly to someone else. The fact that the environment needs to be consistent for both people would also be a problems as I often find strong opinions from  developers in technology as to how they want an environment configured for their tasks. I know that watching someone else control a browser drives me a little crazy. I think I’d definitely need to have a separate machine for many tasks.

    As with anything, pair programming makes sense at times. I know that I’d like to have senior T-SQL coders work with junior ones when developing complex queries and explaining how and why they solve problems with certain techniques. Doing this in real time might slow down the senior person, but I think the evolution of one’s thoughts as they solve a problem is as important to learn as the inner workings of the actual code.

    The Voice of the DBA Podcasts

    We normally publish three versions of the podcast each day for you to enjoy. Today there is no podcast due to Steve being ill. Hope to have the podcasts return tomorrow.

  • Trade-offs

    scale
    There are always trade-offs when building software.

    I’ve always told my managers that building software is a trade off. We can do things cheaply, or we can do them quickly, but we can rarely do both. We can certainly fail in both ways, and many people do, but I usually see the need to trade time for money, or vice versa, when building software.

    I ran across a piece recently that was similar, though in it Allan Hirt says you can do things right, do them fast, or do them cheap. Allan talks about limited resources in working on projects. At some point time, budget, and staff resources are constrainted and you can’t expect stellar performance on extremely large workloads in a 24x7x365 environment. Something has to give, and one of those resources is going to let you down.

    I had always looked at people as a “money” cost, since they are paid for work, but there is another constraint to people that I hadn’t considered. Each individual in your company isn’t just a resource that’s exchangeable for others. Each individual has knowledge and skills that aren’t easily transferred to, or replaced by, other employees. In addition, each person has time constraints; they will only work so much in a given time period.

    Building powerful, efficient, effective systems, whether in software, infrastructure, or even in culture takes effort, time, and money. However if you do it well, it’s something you’re not only proud of, but something that pays for itself over and over.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Transferring Table Types

    An interesting idea. I saw this question asked after I was playing with table types a bit. “Can you move a table type between schemas?”

    Suppose I had two schemas:

    CREATE SCHEMA OldSchema
;
GO
CREATE SCHEMA NewSchema
;
GO

    In one of them, I create a table type and a procedure:

    CREATE TYPE OldSchema.MyTable AS TABLE
( IDCode INT
, Location VARCHAR(200)
)
;

CREATE PROCEDURE OldSchema.MyProc 
AS
 SELECT * FROM dbo.MyLogger
;

    There’s nothing fancy here. Just two objects created in one schema. I now have the need to move these to the other schema. Perhaps it’s a mistake. Perhaps I have developers working in one schema and I do integration testing in the other schema. In any case, it’s easy to move the proc with the ALTER SCHEMA syntax:

    ALTER SCHEMA NewSchema TRANSFER OldSchema.MyProc
;

    I can easily script something to move multiple procs, but if I do this:

    ALTER SCHEMA NewSchema TRANSFER OldSchema.MyTable
;

    I get this:

    Msg 15151, Level 16, State 1, Line 1

    Cannot find the object ‘MyTable’, because it does not exist or you do not have permission.

    I know it’s there; I just created it. What’s wrong?

    The problem is that this isn’t an object per se, but a type. As a result, to move a type, I need to use a different syntax:

    ALTER SCHEMA NewSchema TRANSFER type::OldSchema.MyTable
;
GO

    That works fine and the type has moved. The class attribute of the notation is

    CLASS::Schema.Object

    I haven’t found good documentation of this, but there are numerous examples in BOL that show this is how you address various “types” in SQL Server.