Dynamic-SQL Act I

Sometimes I wonder if I ever learned anything in my collegiate Computer Science classes. After all, most (whom I’ve heard) would say that, unless you’re going to be developing The Next Big Thing, then you’re wasting valuable time and money on cheap beer and expensive lectures. My father always said that “If you want to party, go to college; if you want an education, get a job.” This, for some, may hold true. The expensive lectures I was no stranger to; the cheap beer, however, I tried hard not to touch with a 39 ½ foot pole.

But, no matter how dumb you play, something seeps in. That’s how you weed good teachers from the mediocre ones: they can disseminate knowledge without you even knowing it. They’re kind of like God, in a way; sometimes the vague answers and delayed responses aren’t intended as insults or shirking, it’s a device to make you think and learn for yourself. Sometimes, when you think you need a helicopter to save you, a properly thrown life vest will do just fine.

While at Pittsburgh, I had a tough-as-nails professor for my algorithms class. I spent so many nights compiling Java code until 3AM when my throat was sore from too much tea and my eyes bled zeros and ones, but I got the programs working to spec and in on time. It was, for all intents and purposes, a trial by fire¹. At the end of it, I thought I would forget everything and never use an iota of what it tought me for anything practical in my career. This view was incredibly, humerously, short-minded.

For a while, it was correct. Still, something lingered, and I should be glad it did. What remained was a desire to apply what I’d learned to what already existed. Solving old problems with more efficient solutions is always a challenge. It’s why neural networks and packet routing have evolved. But with these challenges comes personal and professional rewards, not the least of which is the ability to re-use the mental framework for the problem solved.

One of my least-favorite problems was graph search. (There’s a reason no one but mathematicians specialize in developing, proving, or otherwise entrenching themselves in graph theory.) Yet, graph searching is one of the most widely-applicable skills a software architect can develop. Case in point: dynamic SQL construction.

As a mental exercise in theory and practice, there are several parts to this post, interleaved with time for mental stretching, retractions, and analyses & comments. (This is also no coincidence, as for those literary-educated readers the scaffolding is of the classical drama; enjoy.) This is Act I: Exposition.

In my experiment, there are three factors:

• tree complexity,
• semantic-path evaluation, and
• reasonable application to graph theory.

Tree complexity is the time and effort required to maneuver ‘blindly’ from one entity to another, 2-hop-away, entity in a database. Semantic-path evaluation is the real-world implication of the statement’s conjoined entities. For instance, using the tables Painter, Plumber, and Person, a Person can become a Painter or a Plumber but each has a specific role and though both may use water they may not be what we intended to achieve. Without predefining rules, the system will have to build an assumption based on the entities provided. Lastly, while possibly obvious, the application to graph theory may need to be spelled out; this will probably be spent the least time developing.

If you can think of anything I’ve missed or misunderstood, constructive criticizm is encouraged! Act II: WYSIWYG will hopefully follow soon.

¹Taking the class alone isn’t the Pitt CS Trial by Fire. Taking 1520 and 1550 in the same semester is. To exit both classes with B’s was a personal accomplishment, as well as bragging rights.