Iâ€™m trying to beef up my writing about XQuery in advance of the upcoming PASS Summit 2013; I got accepted to present, and I want to make sure that I start covering a lot of topics related to XML so that Iâ€™ve honed my focus a bit. Unfortunately, blogging doesnâ€™t come easy to me these days, and while I would generally start a session from the beginning and move forward, I think it would be best for me to start with something easy for me to write about, even though it means Iâ€™ll be doing a bit of backtracking later.
A little bit of background
As you may already know, SQL Server supports XQuery against an XML data type through the use of five basic methods:
Conceptually, each of these methods act a bridge between the the SQL processing engine and the xml parser baked into SQL Server. This concept of a bridge allows me to think about where query work is being performed; is it being done as a SQL statement against the table containing the XML fragment of interest, or is it being performed by XQuery before bubbling up to the SQL level?
I want to focus on probably the easiest method against the xml datatype: .exist(). Simply put, this method checks to see whether or not the results of an XQuery expression against the supplied XML value are nonempty; it returns 1 if true, and 0 if false. Letâ€™s start with a simple sample:
DECLARE @T TABLE ( ID INT, x XML ) INSERT INTO @T ( ID, x ) VALUES ( 1, '<root><plant><fruit>tomato</fruit></plant></root>' ) , ( 2, '<root><plant><fruit>banana</fruit></plant></root>' ) , ( 3, '<root><plant><vegetable>tomato</vegetable></plant></root>' ) SELECT ID, X, x.exist('//root') AS "Does It Exist?" FROM @T
Running this query will return the following results:
Every row has an XML value in the X column which contains a node named <root>. We can change the output to identify rows which have vegetable nodes like so:
SELECT ID, X, x.exist('//root/plant/vegetable') AS "Does It Exist?" FROM @T
The results then change to the following:
.exist() can also be used in the WHERE clause of a SQL statement; if we want to identify only the rows which have an XML fragment containing a tomato, we can alter the SQL statement like so:
SELECT ID, X FROM @T WHERE x.exist('//.[text()="tomato"]') = 1
Note that the .exist() method interpreted an XQuery statement to look for nodes which had a text() value of â€śtomatoâ€ť; two rows matched that requirement, so .exist() returned a 1 for those two rows to the calling SQL statement, and the WHERE clause identified those two rows.
So, Iâ€™ve covered a few basic concepts while talking about the .exist() method:
- The xml methods act as a bridge between XQuery and SQL for the xml data types.
- The .exist() method supports XQuery expressions including both simple paths (//<node name>) and XQuery functions (e.g, text()). This will become important later when I get around to discussing FLWOR.
So, last Saturday, I went to the first SQL Saturday in Atlanta that I had absolutely no responsibility on the actual day of the event. I wasnâ€™t an organizer, I didnâ€™t really even volunteer. As a chapter leader for AtlantaMDF, I do have to go in and pay the bills later this week, but for the most part, I got to walk around and revel in the day.
And it was a good day. The team (led by Geoff Hiten) pulled off another great event; 555 people attended the event, and there were some AWESOME sessions throughout the day. I was in the 9 am slot, and my session on Biggish Data went well, even if (as usual) I had WAY too many slides. Speaking of slides, you should be able to download the deck from the SQLSaturday 220 schedule (as well as many other great presentations). I did have to slip out early since this weekend was my weekend with the kids. My current youngest (Grace) had to get service hours for beta club, so she got to hang out with me, but I needed to get back home early to hang out with the oldest one.
So what was cool? What did I learn?
- The number one highlight for me was watching Louis Davidson demo Red Gateâ€™s SQL Monitor tool, and he chose one of my custom metrics to use in the show. I respect Louis a lot, and it made my day.
- I learned that I need to cut out about 10 slides out of my presentation.
- I had a great conversation with a few people about table partitioning and performance gains; I think thereâ€™s enough material for a future session explaining why you will or wonâ€™t see performance benefits from partitioning. Hmmmmâ€¦.
- I had another excellent conversation with Robert Cain regarding the growth of SQLSaturdayâ€™s, and bounced around a few ideas about moving to a mid-tier model. Kind of like what SQLRally was supposed to become, but different.
- I also got to hang out with Andy Leonard. He and my Grace had a good time discussing movies (Whereâ€™s my super suit?).
Mostly, I just got jazzed about being back in the #sqlfamily. Hopefully, I can build off that momentum, and start blogging again. Granted, the next few months are going to be personally interesting, but I need to make time to share again.
I know; I suck at blogging.
Anyway, I have a couple of upcoming presentations this month, so I figured I needed to get back and gear and at least post a notice about them. First, Iâ€™ll be presenting at A Bunch of Devs (http://www.meetup.com/A-Bunch-of-Devs/) on the Red Gate development suite of tools. Funny story; I actually work in that building. The organizers reached out to Red Gate to see if they had a Friend nearby. I guess I qualified.
Next, Iâ€™ll be back at SQL Saturday Atlanta to present on Biggish Data; this is the first Atlanta SQL Saturday that I actually had almost nothing to do with (as a chapter leader, I helped with some basic decision, but very little). Iâ€™m excited that itâ€™s continuing to thrive. Says a lot about the infrastructure that PASS puts behind these events; they just need a little help from the local chapters, but they donâ€™t rely on the same person getting burned out year after year.
Just a quick note; SQLSaturday is coming back to Atlanta on May 18, 2013. This free (lunch is optional) event usually sells out way in advance, so you may want to go ahead and sign up. Also, the speaker lineup tends to fill up pretty quickly (call for speakers closes 2/24), so if youâ€™re a SQL Rock Star or just want to share your knowledge, go ahead and submit your session as well!
So, January came and went, and no post from me. I continue to suffer from writerâ€™s block, but Iâ€™ve finally cobbled together enough ideas that I feel like I can put a couple of quick posts out there. Iâ€™m still struggling with learning how to manage a technical team (MaTT) as opposed to being a technical person, but hereâ€™s another concept Iâ€™m beginning to grasp.
You have to start somewhere.
When I began managing my team, I was tempted to rush in and save the day. I know where a lot of the problems are, and I know which ones are big, and which ones are not. I kept thinking that if I could just motivate the team to start attacking the problem, then weâ€™d be sitting pretty in a year.
I was wrong.
Most people are already motivated to do their jobs; if theyâ€™re not, then theyâ€™re in the wrong position, and itâ€™s hurting them as well as hurting the company. What a team is usually looking for in a manager is to help them make priority decisions, and to back them up when they need things to change. Hereâ€™s the conundrum: Technical people often (logically) focus on changing the things that hurt them the most. Your DBA may say â€śI keep having to babysit this query for the boss because itâ€™s slow, and itâ€™s slow because the developers donâ€™t know how to normalize a database; can we refactor everything?â€ť. Your developers may say â€śIf we had more time to rebuild everything, we could fix that query; can we hire another person or put these features on hold so we could tune everything?â€ť. Your boss may say â€śWe need to make a profit; whatâ€™s the most cost-effective way to manage our database architecture moving forward?â€ť
If you focus your energy on addressing the technical issues without giving consideration to the profitability of your company, youâ€™re spinning your wheels. However, you MUST figure out a way to ease the pain of your technical team by addressing their concerns. Itâ€™s no secret that Iâ€™m a Lean/Agile kind of guy; I truly believe that these philosophies can help balance the scales between support/development/operations, but you have to start somewhere.
â€śSomewhereâ€ť for me is the small fixes; donâ€™t tackle the big projects head-on. Focus on being successful at a couple of small things (e.g., reduce the number of support calls in a measurable fashion, or refactor some small but essential bit of code). Make sure that these changes are measureable, and make sure that you report the changes to your boss AND to your team. This accomplishes two things:
- It shows measurable progress (in my experience, bosses love metrics), and
- It encourages your team by giving them a couple of quick successes.
If your team doesnâ€™t see progress, then in their mind, â€śnothing is being doneâ€ť. Your boss wants to know how youâ€™re improving efficiency and effectiveness in terms of dollar signs; your team wants to know that theyâ€™re solving a technical problem. Make sure you can address both of those needs.
More to come.
This has been a busy year for me; apart from all of the personal news, Iâ€™ve spent the last year feeling out my new position as a manager. While is not my first job as a manager (I spent about 3 months as a manager working for a department in a death spiral in 2002), itâ€™s been a bit of a bumpy ride. Iâ€™m learning as I go, which is a great skill to have as a technical person, but tricky in a management position. Hereâ€™s a short list of things Iâ€™ve learned over the last year, and I hope itâ€™ll be useful to those of you that are making that transition yourself:
1. These ainâ€™t the problems youâ€™re used to solving.
As a database person (DBA, Developer, Architect), I was very accustomed to tackling technical challenges on a daily basis. Disk running out of space? Check for unexpected log growth. Bug in a procedure? Rewrite it and test. I just assumed that as a technical manager (managing a group of DBAâ€™s) that I would continue in that vein, just with more help and more paperwork. I was wrong (so wrong).
You see, most of the problems I face today arenâ€™t technical; theyâ€™re people and processes. Iâ€™ll talk more about the people in a bit, but the process issues stem from things like "we canâ€™t get this bug fixed because the devs are busy writing new featuresâ€ť or â€śI have 35 things to do on my top priority list; which one do I do nextâ€ť. As a manager, my primary obligation is not to make sure that technical problems are addressed, but rather to make sure that there are no impediments for my team to implement technical solutions.
2. The people in your department arenâ€™t you.
And they donâ€™t solve problems like you do; they have their own systems, answers, and methods to get to those answers. While it may sound conceited, I think I was a damn good database person as an employee, and I think it was those skills which ultimately led to this opportunity. However, I have quickly learned that not everyone approaches problems the way I do, and I canâ€™t simply jump in and solve the technical problem for somebody. Itâ€™s tough, especially when I see that one of my employees took a few hours to google something I knew how to do blindfolded, but I have to let them learn at their pace (and encourage them to learn faster).
One thing I have learned is that I have to make time to pass on my skillset, and thatâ€™s not a one-time thing. I need to spend some recurring time collaborating with my team so that I can step away from solving the technical problem and focus on the impediments (see rule 1 above).
3. Donâ€™t let the drama get to you.
As an employee, it was fun to be snarky. When something (or someone) ticked you off, you could go ahead and rant about how stupid the decision was or how bad the system sucked, all the while knowing that you would be doing your best to fix the problem the next day. Your words didnâ€™t really mean much; it was just a way of blowing off steam. As a manager, other people are watching you, and you canâ€™t blow off steam (in front of them). Compounding the problem is the fact that as a manager, people come to YOU to rant. All you can do is listen and try to get to the core of the problem; again, if thereâ€™s a real issue where it looks like the train is going off the tracks or your team canâ€™t accomplish itâ€™s objectives, then you need to be able to delve into that issue and resolve it. But you canâ€™t participate in their rant session; listen, decipher the issue, and then take action.
4. Find time to stay technical.
As an employee, I can tell you that itâ€™s tough to work for a manager that doesnâ€™t understand what you do; donâ€™t become that manager. I canâ€™t stay abreast of every specialized aspect of SQL Server, but I can keep up with the gist of things. I may not be up to speed on the latest and greatest design patterns, but I need to be able to have a conversation with a developer and understand what theyâ€™re trying to do. Iâ€™ve recently started studying for the MCSA on SQL Server 2012; I havenâ€™t been certified on a platform since SQL Server 7. I feel itâ€™s important to show my guys that Iâ€™m trying to stay a technical resource for them, and also encourage them to pursue more knowledge. The expectation in our department is that research is part of our jobs.
I used to dream about being an Microsoft Certified Solutions Master; I put that dream on hold so I could take care of my personal life, and now it looks like Iâ€™m walking another path. It doesnâ€™t mean that I canâ€™t be a technical person; I just will have a broader repertoire.
5. Change is hard; get over it.
I just got back from the first week of Model-Netics training which is offered by my employer in a four week series (over four months); one of the first models we talked about was the change curve, which looks something like this:
The idea is that everybody is plodding through life at a certain level of productivity and morale, and then a change occurs (a promotion, a formation of a new department, a new process gets implemented, etc…); suddenly everything is askew, and productivity and morale go sliding down the mountain toward the valley of despair. At some point, acceptance will set it, and if the change is a positive one, productivity and morale should settle in at a new high.
Scholars will note that the change curve is widely used in terms of the 5 stages of grief, but the point of it is that normal acceptance to a change takes time, and a realization that things are different and youâ€™ve got to adjust to the new normal. I went into this management position thinking that I could quickly bounce into doing the things I wanted to do, without realizing that it was going to take some time for me to adjust to my new responsibilities. I also had to balance the productivity and morale issues in my new department (as well as my old one). That realization is the basis for transitioning from a slide into a climb.
Itâ€™s been an interesting first year, and Iâ€™m looking forward to the new challenges ahead. Iâ€™ve never worked so hard in my life, but yet I feel like my job is important to me, and at the end of the day I can put it down and focus on other things. Life is about more than a career.
Everyone does one, so I figured I should Unfortunately, I barely recovered from my trip to Seattle, and am now rushing out the door to Dallas for company training, so Iâ€™m afraid this will be brief. I do intend to blog more in the future (promises, promises), but for now, hereâ€™s the highlights:
- Day 1 Keynote rocked; it looks like SQL Server vNext will be an awesome release for DBAâ€™s. 2008 and 2012 brought a lot of cool things to the table development/BI â€“ wise, but less love for administrators (IMHO). Hekaton will change that.
- I was really burning out on the whole chapter leader/SQL Saturday/community activist thing; three days in Seattle changed that. Weâ€™re now planning Atlanta SQLSaturday 2013 (woo-hoo!!)
- The Chapter Leader meeting format was very effective, and a big difference from previous years.
- Session planning seemed a little â€śoffâ€ť this year; too many people trying to cram into too small a space. I missed some good sessions because the rooms were too full.
- I got bit by the cert bug, and passed exam 70-461 Querying Microsoft SQL Server 2012 on the second try. I flunked it on Wednesday, got pissed off about it, crammed that night, and passed it on Thursday. More on that later.
All in all, it was awesome. I had a great time reconnecting with people, and Iâ€™m looking forward to the year to come. Gotta run; the Atlanta airport is an hour away. I have no clue how you road warriors do thisâ€¦.
So, there it is. Two little lines, and BANG! Iâ€™m going to be a dad again. Itâ€™s been 14 years since Iâ€™ve last seen a positive pregnancy test, and Iâ€™ve got to tell you, the mixture of excitement and downright panic doesnâ€™t really change. True, Iâ€™ve got a lot more experience under my belt, but then again, Iâ€™ve got a LOT more experience (Iâ€™ll be 42 in July). Wow.
We heard the heartbeat today, so my wife is officially 7 weeks along, and except for a few close friends and family members, weâ€™ve been trying to stay quiet and think happy thoughts. Weâ€™re finally out of the woods far enough that Iâ€™m comfortable telling people.
Comfortable may not be the right word; Iâ€™m still slightly in shock, but Iâ€™m significantly more optimistic about the outcomes. Iâ€™m going to be a dad, again. Itâ€™s an amazing feeling.
My head is still swimming with the news, but I hope this explains why I havenâ€™t blogged much over the last year, and why I probably will be sporadic for the next few years . IVF is a time-consuming process, but as I recall (sheesh, I sound like a geezer already), so is raising a baby. At least this time around Iâ€™ll have a couple of high-school students to help out. My two daughters are thrilled about the possibility of a little sibling; both are hoping for a brother, but as my mom put it, my â€śtrack recordâ€™s not so great in that areaâ€ť.
Other words of wisdom from my mom: â€śyou better get your ass to a gym.â€ť Iâ€™ve got less than 9 months to get into the best shape of my life; Iâ€™ll have a rugrat to wrestle. Life is good, and I need to be around for a long time to enjoy it.
Itâ€™s hard to believe that the Summit is next week; Iâ€™m just now pulling together my schedule, and Iâ€™ve got some tough choices to make. I have noticed a pattern, however; this year, Iâ€™m going to sessions for new features and possible solutions as opposed to â€śOMG, I have to solve this problem NOWâ€ť kinds of sessions. Iâ€™m also going to sessions where I think my team should get more knowledge, not just the things that interest me. I guess Iâ€™m finally growing into this management role.
Below is my tentative schedule; see all the red? Thatâ€™s double-bookings, or even triple booking. Sigh. Iâ€™m also planning on getting enough liquid courage this year to SQLKaraoke (although many of you may wish I donâ€™t).
OK, so I havenâ€™t blogged in like, foreverâ€¦ (and apparently, Iâ€™ve adopted the speech pattern of a teenager from the 80â€™s while I was away). Suffice it to say that Iâ€™ve been working on a few major projects, and Iâ€™ll fill you in on them later. I did want to pick up the torch again, and thought I would write a quick email about the three books that are currently on my reading list:
On my iPad (and no, I didnâ€™t get a Surface RT, and it sounds like it was a good thing I waited), I recently picked up Managing Humans by Michael Lopp. Itâ€™s a fun read, but his principles and axioms are a bit like the Book of Proverbs; itâ€™s a loose collection of ideas on how to manage software engineers. Iâ€™m a bit more simplistic than he is, and itâ€™s tough for me to put all of the puzzle pieces together. Iâ€™m still digging my way through it; itâ€™s fun at times.
My technical book of choice as of late is Practical PowerPivot & DAX Formulas for Excel 2010 by Art Tennick. Weâ€™ve got a new self-service BI initiative at work, and my department is responsible for evangelizing the capabilities of SQL Server. What Iâ€™ve seen so far of PowerPivot, I like, but there are a few challenges; Iâ€™m not an Excel guy, and so the interface is not intuitive for a DBA. This particular book has been helpful on more than one occasion when I’ve been frustrated by my lack of ability to get the software to do what I want.
And now for pure geekiness (and Iâ€™m sure my wife is shaking her head at this one), I recently found the entire Apprentice Adept series from Piers Anthony in a used bookstore. This was one of my favorites in my early high school career (yep, I was a nerd), and I just started reading Split Infinity. My excuse is that I bought it for my teenage daughter, but in reality, its for me .