SQL is SoQooL

SQL is one of my favorite parts of this class so far, because the most difficult aspect of using a virtual machine has been struggling with how it is organized. I didn't make the directories and in order to see what is where I need to remember commands. But with MySQL I am organizing things myself, and when I query and recognize results returned to me I feel good. Powerful. Organized.

The conceptual organization of databases is the part I get stuck on sometimes, but as this is what I hope to do with my life, at least in part, I'm workin' on it!

SQL N ERD R Q!

(Q is my husband's textese for Cool)

Why is it that when I'm not in computer class I feel like such a geek for over-organizing every little object and interaction? Yet when I study database design I feel incredibly outgeeked?

In any case, I've adopted a tentative rule to keep up: If you've got a many to many, M:N, MN, or mucho a mucho relationship, just stick a bridge in between entity number 1 and entity number two. Borrow the primary key from each of those two entities, maybe throw on a date or time to make the bridge represent unique instances, and voila: normalization.

The hardest part for me has been to figure out what is and what is not many to many. We read of an example of plants and waterings. The author said one plant can be given many waterings, but one watering can only be given to one plant. This was confusing. I garden. I water more than one plant at a time. It's called the mist setting, a big cloud of water. Get outside database designer, experience the bounty of the mist setting!

But of course that author has a point. He's talking about an instance, a measured and clocked watering instance. The hibiscus got two cups of water at 1:32pm on June 24th.

I enjoy this parsing and labeling business very much, by the way. I've started wondering how I can find an internship that involves this kind of activity. I enjoy ERdiagramming too, and even decided to use a SmartDraw free trial. Unfortunately it's only 7 days, and it stamps a huge proprietary watermark on everything I create. Don't these people know I'm unemployed? I don't pay for software that irritates me, I don't even pay for software I like!

Tech Plan...or Toilet Paper

In his post Life is what happens to you when you're making other plans, Blogger Michael Schuyler calls the technology plan "a political document." You bet it is. Of course it's been said in other discussions of technology plans, but I like Schuyler's because it discusses one reason for the phenomenon, which is that most of the people reading a technology plan know very little about computer craft. Like those folks in Washington talking to the millions of Americans who know so little of statecraft (in addition to the few who do know a thing or two): you have to pack a real plan in its own mystique to sell it to those who don't get the science.

Technology plans remind me very much of grant-writing, and reading some of the poorer ones call back the days when I was a lowly administrative peon (which is less lowly than my current state of pure unemployment, but still). If you were like me, you may look upon the instructions for the E-rate tech planning with hope, thinking, let's use this huge document as a reason to remake our organization. But then the boss says, oh for heaven's sake just make something up so we can get the funds! And the boss is right--with resistance at the top, that organization is probably doomed to writing fiction to bring in funds. Once the funds are acquired, TP stands for toilet paper.

The best thing the administrative peon can do: Move on. Move up. Build a better organization, or at least start working for one, that embraces opportunities to improve.

xlink, xpointer, xml, xciting....

I learned quite a bit about XML in IRLS 515 last semester. But of course questions remained. One big one was answered by the following section from http://www.w3schools.com/xml/xml_usedfor.asp :

"--XML Separates Data from HTML

If you need to display dynamic data in your HTML document, it will take a lot of work to edit the HTML each time the data changes.

With XML, data can be stored in separate XML files. This way you can concentrate on using HTML for layout and display, and be sure that changes in the underlying data will not require any changes to the HTML.

With a few lines of JavaScript code, you can read an external XML file and update the data content of your web page. "

As fits best with my learning style, my remaining questions were best answered by searching online myself. I was wondering, how do you link xml and html documents together? I saw the examples of xml docs enhanced with css, and I know how to do that, but what about adding links and such? How do you link a photograph to its xml description?

Of course my question sent me right back to the W3schools site, to the xlink and xpointer tutorial. I'm working through it currently but you'll see a link to my use of it if I ever get there!