It’s Tuesday somewhere when this post goes up. In fact when this goes live it will be sometime around Tuesday afternoon or evening in Adelaide Australia. Why there? This month’s “T-SQL Tuesday” is being hosted by Rob Farley over at his place. His topic is “relationships”. He talks about the history of T-SQL Tuesday over at his post and I encourage you to check it out.
In honor of Valentine’s day, he wanted us to all chat about relationships with no other specificity other than having some sort of a relationship to our day jobs with SQL Server. A few directions came into mind, come along on a journey through the rambling thoughts in my mind. Let me know what you think in the comments, I’d love to hear your opinion.
Customer Relationships
This past weekend I experienced some customer service that made me think back to my own abilities in this area (and where I can improve). You might read about another such lesson I learned at my town dump a few months back when posting about the importance of attitude at work. Anyway, I ordered from a smaller pizza store in town. They don’t get a lot of business (new kid on the block) but I wanted a calzone. The former owner (and older Greek man) made a good one with Spinach, Feta, Mushrooms and Kalamata Olives with olive oil and garlic. Called and ordered that. No questions/complaints (Until I got there). To continue the point let me contrast how I came upon this idea of a calzone with the former owner…
A Positive Example
Now the former owner used to have to chop the non-pitted olives up but he offered to do that. In fact when I was first in there and ordered the calzone without the olives he got excited and said something like, “no one up this way ever wants something like that.. they want sauce and pizza cheese.. How about we put some olives in there too?” He made it up, we chatted while it cooked and he took an interest in me. Asked me questions about my family, about living in town, etc. Nothing annoying, nothing prying. He just seemed to care about me. I asked him about business, about Greece and we just chatted between customers picking up orders (Did I mention I live in a small town? Smaller shop, not a lot of business unfortunately.. The popular pizza place has been established by another Greek family for some time and they dominate the “market”). Great Calzone and I ordered it from time to time…
Under New Management
Flash forward to this past weekend. I called up, ordered this calzone for the first time with the new owners (I knew there was new ownership because we ordered a pizza a while back and the young owner was quick to ask “have you been here recently? we have new ownership… I just wanted to let you know our prices went up so you aren’t surprised”). No questions/comments over the phone, I even said “the old owner used to cut up the olives, if you guys can that’s great otherwise don’t worry about it”) When I went to pick it up the owner, his mother and a female employee were lazing about and I was greeted not with a hello but with, “Just so you know… Those olives are expensive, we normally use regular black olives on pizza. Plus there are pits, my mother had to cut them up with a knife.. If we do this for you next time we will have to charge you 1 dollar.” I had already paid and didn’t offer to pay the difference (price was already astronomical ) but I did say, “oh.. sorry I used to get them like that with the other guy”… The response? “Yeah.. That old guy used to always do special requests for customers, that’s one of the reasons he isn’t here anymore, you know?” I didn’t comment on the fact that the “old guy” was just one person working, here is 3 people with one customer.. I just nodded and left, likely for good until this guy goes out of business and new management comes in…
The Day Job Lesson?
Yeah, I know. Conciseness is key but the story above illustrates a few points to remember with the relationship to our “customers”, managers, vendors, etc. As a DBA, the developers are my customers. To a developer, perhaps a DBA can be seen as a consultant or vendor. No matter how you define it, a relationship exists. Customer satisfaction is a good goal. Some thoughts:
- Going the extra mile isn’t always bad – At the pizza place doing extra for each customer may not be wise but every once in awhile? Might make a repeat customer. As a DBA, always doing something extra for every customer may mean a week that never ends. But… There is a happy medium. Where you can do so safely, a little more is a good goal.
- Why are you telling someone the impact to you? I am not saying don’t tell them but ask why. If you are just whining to brag about how you went above and beyond and complain at how horrible it was for you, save it. Save your breath. Just quiet down and go and beat the expectations for the sake of doing a good job.
- Happy Customer – Happy Provider- At the pizza place a happy customer means I’ll go back. As a DBA? Maybe a developer will be more likely to listen to some advice or guidelines if you aren’t always whining, complaining and doing the bare minimum.
Relationships Work
I used a lot of my words in the above post. Just a reminder here that set based logic and normalized databases generally work out just fine. I still hear people come to job interviews and say things like “normalization is a great concept academically” or “I never normalize too far, then there are too many tables”. Blah. Blech, even. I am not saying every database needs to get to the highest level of normalization but go for it and try a higher bit of normalization than you are currently willing to. Performance and Integrity will thank you. Sure, in some cases the read performance might even take a slight, barely noticeable hint. But your maintainability, data integrity and update/insert cost may just improve at the same time for a couple ms here or there.
The rules of normalization still apply (40 years later! That is pretty neat… I work with in 2010 in IT with a technology that is by and large based on the same bedrock that was there before I was born.. not a lot of .net developers can say that 😉 and it isn’t “legacy”) and good database design eliminates many performance problems. In fact taking the time to properly design your database today will mean there is a much slimmer chance that you’ll ever need to hire the likes of me to come in on a tuning or “what the heck is happening to data quality!?” project. Louis Davidson (and others) wrote a good book on this subject, Pro SQL Server 2008 Relational Database Design and Implementation , is a great resource (so are his earlier versions). The first section of the MVP Deep Dives book which covers design decisions is worth the price of the book alone (then you get a bonus of a multitude of other, post-design concerns in the book)
Go and read some of the early papers in the life of the database as we mostly know it today, like this paper from E.F. Codd. Heck – spend some time clicking around in Wikipedia even, start in normalization and click on what you don’t know. Then apply some basic principles:
- Normalize your database. Go through the motions and understand normalization and ask the right questions of your data model (joins are not inherently evil, especially in 2010 with DBMS’ and hardware where they are…)
- Define your relationships explicitly at the database level if you care about integrity (sure there are some cases where you may be better served not to but in most databases I have worked with, they would have benefited from integrity and possibly join elimination for some outer joins to dimension tables)
- Model – No, wipe that zoolander face off please… Model your database, define your relationships before you start working. Some seem to have the, “real data professionals don’t do data models” mentality – That’s bull. (though, I’ve had quiche from time to time, so your mileage may vary).
Check out the rest of the links that will go up on Rob Farley’s SQL Blog at the conclusion of this event. I am sure there will be some great posts (and then there will be some like this random relationship rambling but it will be worth it when you find the good ones)
What do you think? Should us DBAs send Valentines to our developer friends like our kids do at school?
Interesting story. I’m reading Seth Godin’s Linchpin right now, and he would say that the original owner was an artist, and the new owner is a cog. By his definition, an artist is someone who gives of themselves and creates a positive experience for another person. He cared about his calzones and was passionate about making customers happy. The second owner (who will not be an owner very long) is following an instruction manual. I would love somebody to ask that guy to calculate which is more expensive; calamata olives or losing a customer. People who follow manuals are cogs. They are not remarkable and very, very replaceable.
So your list of day job lessons is good. I’d just add one more. Being unremarkable and following the manual makes you a cog. Cogs are replaceable. Don’t be a cog.