T-SQL Tuesday #30: A DBA’s Ethics

By Airborne Geek on May 8, 2012

T-SQL Tuesday 30
#30: Deep T-SQL Tuesday or Deepest T-SQL Tuesday?

Chris Shaw (blog | @SQLShaw) brings us T-SQL Tuesday this month. His topic of choice is “A DBA’s Ethics”, which is a pretty deep subject! I feel like this post goes off the rails a little bit compared to the direction of the invitation post, but I had something happen last week that really made me think about this topic in a specific way.

Chris says, “Don’t consumers and business owners have to trust someone at some time with their data?” This is a line that I have clung to in the past; at some point, it has to come down to trust. Since I feel this to be true, it makes me somewhat crabby when regulations & whatnot seem to step in the way of that trust, possibly making it hard for someone like a DBA to do their job due to data or system access restrictions. I do believe that there are times and places for regulations like this, and after what I learned last week, I’m probably more on the side of these types of security regulations than I was before.

NPR to the Rescue

See, I wasn’t even sure if I was going to write a post this month or not. I wasn’t sure what I wanted to talk about or if I was even going to be able to get enough coherent thoughts together. But then, one day last week, I was minding my own business (more or less), driving home from work, listening to WPLN, as I am wont to do, when this story came on. To very roughly summarize for those not interested in spending 18:34 listening (I do recommend listening to or reading the story):

  • Father is upset as his son is convicted of bank fraud.
  • Asks younger son to promise to never get into that kind of trouble.
  • Younger son promises.
  • Younger son starts own business.
  • Realizes one day company is under water.
  • One thing leads to another and 22 years after The Promise, said younger son is convicted of same crime as older brother.

I was interested in where this story would go… I mean, why do otherwise “good” people do “bad” things? At the beginning, I thought that somehow research was going to say that doing bad things “runs in the family” (the older/younger brother angle). As the story progressed into the part where Toby Groves begins asking employees to help, and they agreed, I started to think about how there’s no way I would do such a thing…and how could these people?

When the story got to its punch line, it made me think about how this topic related to DBAs:

We like to help each other, especially people we identify with. And when we are helping people, we really don’t see what we are doing as unethical.

A couple questions developed in my head when I heard it, and as I thought about it more, the questions only got more complex:

  • Are we, as DBAs (or DBA-type folks) at all immune to this type of thinking?
  • Would a DBA be more willing to help another DBA specifically? If so, how thin can we split that hair?
  • What about supplying data for audits? Does that change the thought process?
  • Does having an ethics statement really do any good?

I don’t have answers to these questions—not sure anybody does—but they make for interesting things to think about.

If Only I Had a Psychology Degree

I know the first question I have listed there seems pretty pretentious, but I wound up there due to specific reasons. Of course DBAs like to help other people; that’s not what I’m saying. What I am saying is weighing “helping people” while still operating within “the rules” is kind of what we do. I’ve spent a fair amount of time working directly with developers both on projects and to get projects deployed to Production systems. Although it is nice to be able to tell coworkers “that’s all OK”, that isn’t what we get paid to do; instead, more often than not, we’re paid to say No. Not because we don’t like people or enjoy it, it’s because we are trusted (there that is again) to apply “the rules” objectively to everything we are involved in or are supposed to approve for deployment. These “rules” can be administrative procedures, architectural/design policies, or even something simple like scheduling. Because of the nature of what it is we do, we are used to taking a step back, away from the people involved, to ensure that we do the right thing.

Does making decisions like that on a day-to-day basis make a person able to apply that same objectivity to every situation they ever encounter? Who knows? What about if the situation was changed a bit? DBAs (and sysadmins, for that matter), tend to rag on developers a little bit; usually in a good-natured way. But, I believe that, for the most part, DBAs and Developers are fundamentally two different kinds of people—we tend to think and act differently (and that’s OK). So, what happens if a fellow DBA comes to us with a problem or the results of a mistake and are looking for a way to fix it quietly or sweep it under the rug? Since we identify with the fellow DBA more so than, say, a developer, are we more likely to go along with the cowboy fix, as is pointed to by the study in the NPR story? I mean, if one doesn’t truly stop and think about what is going and what is being asked of them, it’s easy to simply think, “oh, Jim-Bob’s a DBA over on the Production team, surely he wouldn’t want to do anything outside of policy…”

What about the audit situation? This can go both ways: on one hand, one wants to help the auditor do their job by getting them the data they’re asking for. On the other hand, you may be wanting to help your team (or yourself!) out by possibly not supplying everything involved in a request. It’s easy to sit here and office chair quarterback the scenario, but that’s the point—it’s easy when you’re not in the situation  yourself, in the same mindset (or lack thereof), staring the same consequences in the face. Thoughts and actions only count when…well…when they actually count.

This is where doubts about ethics statements begin to creep into my head. It’s easy to read through SANS’s Code of Ethics that Chris pointed out on this fine Tuesday and laugh, being like, “yeah, like I’d ever knowingly hurt someone’s reputation or look up the boss’s salary in the HR DB.” The problem is that opportunity or request might not come up on a Tuesday morning while we’re sitting around reading blog posts over our second cup of coffee—it might come up while you’re having an exceptionally bad day, and all you want to do is make at least one person happy. Before you know it, you might have gone off and done something illegal, or at the very least, ethically questionable.

Does having a company, community, or personal code of ethics keep this from happening? The way I interpret the reported study’s results, I would have to say no. Of course, that’s not true for everyone or every situation—it depends! It depends on a lot of things. So many things, in fact, that it’s completely within the realm of possibility that having such a code and reading it regularly to remind ourselves of the covered items could just cause the right synapse to fire in the right situation to keep us from doing something stupid. Does that make it worth the effort? Probably.

I have to say, though, historically, I’ve gotten crabby about things like this that get formalized. I always ask “Really?!”, because I feel like I’m pretty hard-wired in this department and get a little offended by having a code of ethics thrust upon me. I have to say that I’m a a little afraid after hearing the NPR story that there’s a chance I would let things get out of control before I realized what’s going on. At the same time, though, I realize that having that fear and being alert to it is probably about the best way to safeguard against doing unethical things in the first place.

But…

There’s still a problem here. The problem is that we’re not perfect. Insidious things creep in at the corners without us noticing. Even though we’re trained and practiced in recognizing when something abnormal is going on and to see through the glossy surface down to the gritty details, things can still go horribly wrong due to being stuck in those details and missing the big picture.

I don’t know about you guys, but that NPR story freaks me out a little bit. Do I believe what I said above, about DBAs being used to making similar decisions, makes us immune to this type of “sympathy think” (pardon me while I make up words again)? No! I’m worried I go around every day a hair’s breadth away from starting something highly unfortunate just because I wasn’t paying enough attention or thinking the right way about a task.

Sure, talking about a DBA’s ethics is a little bit different than talking about mortgage fraud, but the fundamental decision is the same: Could what I am about to do hurt myself or someone else? It’s hard to think about that question at every turn throughout the course of the day, but apparently we need to, because once again, our animal brains are being a pain in the butt.

Posted in , Tagged , 1 Comment

T-SQL Tuesday #28: Jack of All Trades Crew, Checking In

By Airborne Geek on March 13, 2012

T-SQL Tuesday—always a good option for helping to get back on the blogging horse.

TSQL Tuesday #28
T-SQL Tuesday #28

This month is hosted by Argenis Fernandez (blog | @DBArgenis), a SQL Server MCM & a #SQLFamily member that I have yet to meet. His topic of choice is “Jack of All Trades, Master of None?”, which is right up my alley, because for pretty much my entire IT career, that phrase has described me. It still does, right this second, but I’m trying to get over that. More on that coming.

Because I should be able to use them to frame out a good story (and because I’m cheap), I’m going to work with the list of questions Argenis has in his invitation post.

Are you specialized? On something? Or anything at all?

Am I anything at all? No, not really, thanks for asking! 😀

Anyway… it’s not really safe or fair to answer whether or not I’m specialized with anything but a firm “no.” I’ve been this way from day one. I don’t know that it’s been a conscious decision to get to this point more than it just happened as a result of being driven by a desire to know how everything works. Sometimes that leads to depth in weird places, which can come in handy while watching Jeopardy! on TV.

My non-specialization situation at the moment includes the capabilities of a decent SQL Server DBA, being what I’ll call “serviceable” when it comes to data modeling, and could still be a sysadmin if push came to shove, in a day job in which I have become the go-to ETL Developer. It’s a little weird, I admit. But, all of those other things help with the current focus. The ETL job is slow, you say? Well, is the server on the floor? Is the latency over the WAN link 700 ms per round trip? All of my other skills help, and that is what I think is the best part of being a jack-of-all-trades: It’s possible to know just enough to answer a lot of your own questions!

I’ve said it before, but another thing I like about knowing a little bit about a lot is you can make friends/commiserate with almost everyone in the IT department.

Are you the SQL Guy at work? Or the one who does everything?

Due to the size of company that I work for, there are very few “Guys” at work—everyone has a specific job (or sometimes jobs) that they do. Basically…near-insect-grade specialization. There’s not room for a jack-of-all trades at larger organizations, in my experience, with the possible exception of smaller, autonomous groups.

Having spent time in one of those smaller, autonomous groups within a larger organization, I was a little bit of the guy who does everything. My whole team was, actually. We were “Windows System Admins”, who ran just about everything except Exchange and the MSFT monitoring platform du jour, plus Citrix to boot. Although each of us had our strong points, pretty much all of us could get through whatever needed to be done and have things work when we were done. I think that just goes along with being a “sysadmin”—being a jack-of-all-trades is almost a necessity. Need to know hardware? Check. Security theory AND implementation? Yep. IIS (Apache as necessary)? Probably. Networking? You betcha. SQL was just one of the things that I did while there, although I did do a lot of it.

Do you code? And configure wireless routers at work also?

Hell no. I mean… not if I can help it. See, when I started in IT for real, I knew one whole programming language: Visual Basic 6. Two classes in school on it, and that was it. I wrote a little print queue viewer/management app while a student (hey, it was deployed on 2000+ machines!), but no real experience. To this day, VB6 is the only real (“real”) programming language I know. Not having a strong coding background does cause some problems occasionally, especially when talking to Developers who are used to DBAs coming up through those ranks. I definitely don’t know much about software engineering theory, and that’s where it shows up the most.

As part of the afore-mentioned sysadmin gig, I wrote a command-line only VB app as an automated interface between a couple of systems, but I’m not exactly proud of that moment, for a number of reasons. The one that applies here is one of the downfalls of being a jack-of-all-trades: it’s easy to cowboy up and do quick-and-dirty things off to the side, because you can. Perhaps even more dangerous: because no-one else can.What happens as soon as you’re done? Well, if you’re not careful, it winds up in Production, and then it becomes a support nightmare; if not for you, it will be for a coworker or the next guy. Either of which may some day hate you when their phone rings at 0300 because the wrong piece of duct tape fell off your masterpiece. I think being a jack-of-all-trades can be a good thing, as long as one of those trades is holding onto whatever processes and standards are in place…and if there aren’t any of those, hopefully one of said trades is coming up with some good organizational processes and standards!

As for the wireless router configuration bit—I try to keep that at home. Pretty sure the network guys wouldn’t like me messing around with those things. Just because I [used to] know Cisco IOS, doesn’t mean I should use it. That brings us to another good specific skill that a jack-of-all-trades should have: Knowing when to sit quietly. This goes for both wireless routers and writing anything in VB6 that has a prayer of ever seeing real, actual production use.

If you had to pick one thing to specialize on, what would it be?

Yeah, about that… All the above said, I actually am going to try to specialize on something. Of course, it isn’t enough to say I’m going to specialize on SQL Server. There’s too much in the product now. I’m going back to the thing that got me truly interested in the prospects of becoming a Data Pro in the first place: Business Intelligence. Unfortunately, I don’t think it’s safe to make that a goal, either. Just the BI side of the SQL Server platform is becoming too broad and too feature-rich to come to grips with. I’m going to have to be content with possibly not knowing anything at all about Reporting Services to focus on what I really want to do: Analysis Services. I actually want to be able to do most of the architecture work surrounding big BI projects, from start to finish (except for SSRS!), but I’m afraid that even just SSAS, including all of its new related technologies, could turn out to be too much.

That, though, is a journey that I hope we can all share in. Because I’m nice like that.

Other Thoughts

Being mechanically wired more than anything, it’s not quite as easy for me to tear down a piece of T-SQL as it is, say, the battery operated toys I used to take apart…Or a carburetor. But thanks to the Internet, it’s easy for me to read about and learn from someone who is more adept at doing that sort of thing. This shows two more helpful skills for a jack-of-all-trades: Being able to read and learn is a really important one, and being able (and willing) to share back out is another good one. You never what kind of DBA trying to configure Exchange you’re going to help out.

Posted in , , , Tagged , 5 Comments

PASS Summit 2012 To-Do

By Airborne Geek on March 5, 2012

Diners Drive-ins and Dives was on the TV just now (it was the first episode I’ve seen of the day, so I hadn’t gotten to the point of stabbing myself in the eyes yet), and Guy was at a place in Seattle that we want to put on a list of things to do this year. Tammy said we should start a list in a folder somewhere, and I thought why not mumble to the world about it.

So, here’s a random list of things that we’re going to try to do when we’re out in Seattle this year, along with a stab at when we might be doing it. Obviously these can all be #SQLFamily events, unless otherwise noted.

Oh, and of course, if anyone knows anything about these places and it would actually be a bad idea to do/visit any of them, please feel free to let us know!

  • Slim’s Last Chance Chili Shack & Watering Hole (1st Ave South, ~Georgetown); Probably hit this place on the way into town due to its location
  • “The spice place”; That’s all I’ve got about it. I seem to recall hearing about this once before, but this is all I’ve got right now

Will add to this as time goes on…

Posted in , , Tagged , Leave a Comment

SQL PASS Summit Recap Part 2 & Lessons Learned

By Airborne Geek on February 28, 2012

I really don’t know where November and December went. Or January. Oh crap, it’s the end of February already. Sigh. I’m doing good to not go to the office on a Saturday or start cleaning the house on a Tuesday morning. So, now, I’m finally going to finish what was a little series (err.. OK, two posts don’t a series make) about PASS Summit with this post, which will cover some boring personal stuff, along with some lessons learned back in October.

The Weekend

We were in Seattle until the Monday after the conference, so we had the weekend to do some sightseeing. We planned that since we had never been to Seattle before and we also have a habit of tacking on some vacation around conferences like this for higher quantities of bang-for-buck. We would have rather done this scheduling a little differently, but more on that in a bit.

Alaska King Salmon

Mmmmm

We reserved a rental car on Friday morning, so we could get around outside of downtown. We of course went to the Pike Place Market, which was great. Saw some fish flying through the air, as expected. Went by the original Starbucks, bought some cheese, even some flowers. We actually came back here on Monday morning on our way to the airport to pick up a couple of fish to take home with us. There’s now an Alaskan King Salmon in the freezer in the basement, which I think is pretty awesome. I suppose it’s one’s duty to go to the Space Needle their first time in Seattle, so we did that, too.

 

With the touristy stuff out of the way, Tammy and I met up with Denny (blog | @MrDenny) & wife Kris and set out to see our favorite off-the-beaten-trail thing: dams! Although more lock system than dam, we went to the Hiram M. Chittenden (aka “Ballard”) Locks. Denny & Kris made fun of us a little bit for being “oooo, boats!”, but hey, we’re from Indiana and live in Tennessee now—we don’t exactly get to see water all that often. The complex has a fish ladder where adult salmon can make it upstream past the dam complex to spawn in the freshwater Lake Washington. There’s a viewing area down along the ladder where you can see into the water through windows. October isn’t exactly heavy salmon migratory season, but there was one lone fish in there bumming around. This would be pretty sweet to see when it’s busy.

Negative, Ghostrider, the pattern is full

Negative, Ghostrider, the pattern is full

Somewhat ironically, immediately after this, we went and ate sushi. I can’t drive chopsticks, but that’s a different story.

The rest of the weekend involved closing down the Tap House another time or two, shopping, me piecing out and almost hitting my face on some asphalt in a park, annnnnd sleep. We got back on a 737 for the return trip to KBNA on Monday, and that was that.

Our pics from the trip are on Flickr here. Well, Tammy’s are. Mine haven’t been sorted through & uploaded.

Summit Recap

This conference is crazy. If it had eyes, you wouldn’t talk to it in a bar; you would walk swiftly the other way.

Now, of course, if you’re that guy, it probably isn’t as bad. You come to Seattle, you get your learnin’ on, maybe spend some time with the crew at an Expert Pod to talk through a nasty intermittent deadlocking problem you’ve got, grab some supper, and then head back to your room to catch up on some work or otherwise. I used to be that guy at conferences, so I understand. However, this is the SQL community, which means if you want to take your chances with the crazy, there’s plenty of opportunity.

Obviously, there’s the conference itself. With the schedule full of world-class speakers, small-group interactions with leading experts, and the Birds of a Feather lunch, it is truly amazing the amount of knowledge and experience available for attendees. If you have a question about SQL Server, there is someone here who can answer it (and if there isn’t, then the question is probably unanswerable 🙂 ). I really do enjoy this “learning” part of events. I also love being able to take advantage of the expertise available when I have big nagging problems that I haven’t been able to work out. Fortunately or unfortunately, I didn’t have any such things going on last fall that I was able to pick brains about. For a number of reasons, I hope that is different this year.

Along these lines, something did happen at the conference last year which I haven’t really had happen before: during a few different sessions, I had the realization that I actually knew what was going on. It wasn’t exactly that I felt I was learning for the fist time, it was more the feeling about “getting” such a big chunk of this “working with data” thing that I do. Obviously I don’t really get everything there is to get, as there’s way more to “working with data” than I have my brain wrapped around at this point, but the speakers and the content are just that good—they make you feel smarter than you actually are! I never got this feeling back when I was a sysadmin, doing sysadmin-y things, and I don’t know if it’s because my heart is so much more in what I’m doing now or something else. 

Oh hai!

There are plenty of networking opportunities during the conference day, up to and including ones that I didn’t even know were coming. Case in point: When I would think about it, I would Tweet what session I was sitting down in; or, RT someone else who beat me to it. In one session, I saw a tweet of someone sitting in the same session I was. Into the session, I happened to notice the guy next to me would flip over to TweetDeck on his laptop every so often. I checked out the avatar of the guy who said he was in the same session and I then realized that I was sitting right next to him. It was @DataOnWheels. We talked for a bit & exchanged cards at the end of the session. It was a pretty cool happening.

Some people will say to not feel obligated to go to a session in every slot—that’s what ordering the DVDs of all of the sessions are for. Instead, use the time at the conference to do things that you can’t get for later. Things like hanging out and talking to other people who do the same things that you do that you met at lunch (of which there are plenty of…even I found some!). I can at least partially agree with this advice. However, I’ve been to a fair handful of conferences over the years where, due to one reason or another, the sessions (the learning) were the main reason I was there. As a result, it is going to take me a little while to get over the “sessions are Priority 1” thing. Also, watching the DVDs afterwards just isn’t quite the same as being in the session in all cases. I know as I start to get to know more people (or maybe as more people get to know me), I will be more inclined/have more opportunity to spend part of an afternoon talking about where Microsoft is going with Vertipaq or whatever. This time, I went to a session in every slot except one or two at most, and I’m glad I did that.

One place where we did jump into the social/networking aspect is after-hours. Other than a couple nights where we went back to our hotel and pretty much passed out, we were out quite late. In fact, on the day we flew out to Seattle, I realized later that we had been awake and moving for 23 hours or so. There was SQLKaraoke for one, but for the most part, it was just hanging around at the Tap House talking shop until they kicked us out. Those were some good times. There was the second dinner lots of nights part, which was a little over-the-top. I didn’t really gain much weight that week, and I don’t know how I pulled that off.

Random Bits & Things We Learned for Next Time

Stuff We Should Have Brought More Of. Clothes. The 16 or so hour days that we were running really put an unexpected hurt on our clothes. Tammy noticed about halfway through our trip that one of my pairs of jeans was getting a little… rough (relatively speaking). We got to thinking about it and realized that we were wearing clothes for about twice as long as we usually do in a day, because of how long our days were on this trip. By the time we were heading home, nothing was standing in the corner on its own, but we do know for next time to plan on wearing some things (mostly pants) fewer times than we would normally expect to.

Stuff We Could Have Gone Without. Power Strip. I packed one. It didn’t get used once. I don’t know how it didn’t, and as a result, even though it didn’t get used this time, one will probably come along again next time. This is one of those things that doesn’t take up all that much room, but if it turns out that we actually need it, it’s gold. If we’re tight on room or weight though, this will be one of the first things to go.

Down Time. We found that down time is an important part of the week’s schedule. We cashed out pretty early two nights and it was probably the only way we made it through the week. Basically… we’re not in college anymore. And, likely…you aren’t either. I mean, if you are, that’s cool—we’ll see you a night or two this year at 0300. If you’re like us, though, there will be a few late nights and a couple/few not-so-late nights; and that’s perfectly OK.

Food. Something funny happened in the first part of our week in Seattle last year—we were sick! Long story short, it turns out that we apparently eat better than we thought we did. I mean, yeah, we hardly ever eat fast food, only eat at restaurants a few times a week, and grow a fair amount of the plant-derived food we eat, but I wasn’t expecting to be thrown for a loop by eating nothing but institutional food. This isn’t about any food in particular we had towards the beginning of our trip, it’s just that it turned out to be so different than what we usually eat, it was a shock to our systems. Everything was OK after a few days, but this might be something to keep in mind if you’re a heavy eat-in-type person. At the risk of sounding snooty, we will probably be hitting the Whole Foods that’s in downtown Seattle for some meals at least early in the week to help ease the transition.

Jet Lag. A number of years ago, someone told us of a good way to deal with Westbound jet-lag. See, the problem with going back in time is that you tend to go to bed and get up way early until you get acclimated. The fix is the day you get to your destination, stay up as late as you absolutely possibly can, and only then go to bed. This will make you “sleep in” the next morning as far as your body is concerned, which will hopefully more-or-less land you at the correct time to get up in the new timezone. We’ve done this for a while, and it works really well for us.

The problem is when flying Eastbound. This leads to one staying up and sleeping in way late compared to the prevailing time, which is more of a problem to deal with. This is really bad, because there’s not a good, easy way to deal with it like there is the other way. You just have to go to bed, set your alarm, and hope for the best (and probably be dead for a day or two). On this trip, our first day back in TN, we went to bed at about or normal time, 10:00p Central (8:00p as far as our bodies were concerned). This was only possible because of the craziness from the week before. Turns out this snapped us right back to Central Time in one day! It was by far the easiest jet lag recovery we’ve ever had.

 

That’s it for PASS Summit 2011. I feel bad that it has taken me so long to finish getting this post together. I mean, it’s almost SQL Rally time. I guess one could say the silver lining here is since so much time has gone by, this is a good way to keep the excitement for Summit 2012 alive! We’ve already registered for this year, and we pretty much can’t wait to see our #SQLFamily again.

Posted in , , , Tagged , , , Leave a Comment

Meme Monday: #SQLFamily

By Airborne Geek on November 7, 2011

It’s Meme Monday. This is LaRock’s (blog | @SQLRockstar) brainchild. Its idea is to spur all of us to write something, and my sister agrees that this is a good idea. So, here I am, writing about this month’s topic, which is: what #sqlfamily means to me.

So, what does #sqlfamily mean to me? I love these guys. All of them. Even the ones that don’t follow me back on Twitter and/or think I’m a total muppet (for the record, I don’t care at all if you don’t follow me on Twitter. Alternatively, if you’re not on Twitter at all, I think you’re broken, but that’s a different story). I would say that I love these guys like family, but that would be pretty obvious.

See, the deal is, I’m not a big family type of guy. I don’t know why that is. My family is just as crazy as everyone else’s; nothing special there. Maybe it’s the part about how everyone just expects you to show up for things just because it’s a family function. If that is the case, one of the reasons that #sqlfamily is better is because nobody expects that. We all have lives outside of any one particular thing that we do, so for each thing, there’s always other stuff that we could be doing. We’re all the same in just the right ways, so everyone understands.

That’s another thing—we’re all the same in just the right ways. Tammy and I basically can’t talk about what we do with our family and a lot of our friends, because they just don’t get it. We can’t be like, “yeah, so the business today wanted this report deployed with no filtering in place—all 20,000 rows of it,” because nobody will really get it. Sure, the SQL Community is pretty heavily-weighted towards the Engine side of things, and we’re mostly BI people these days, but pretty much everyone understands at least a little bit. So, what does #sqlfamily get us? People who understand.

Most everyone knows by now (well…umm…) about the wedding at PASS. Like we’ve said before, that was pretty nerdy, pretty over-the-top, and more than a little weird. That description fits us pretty well, so I thought it worked out alright. You know who else fits that description pretty well? Yeah, a lot of #sqlfamily. And guess what? These people understand.

Hopefully you’re getting the theme. That’s what SQL Family means to me: People, friends, family who understand.

There are lots of days where that’s all I am looking for. Thanks, guys <3

Posted in , Tagged , , 5 Comments