I'm surprised at the rather pleasant experience I've had with MySQL. I learned to do a fresh MySQL installation, set up users, and load a particular database almost three years ago, but until this unit I never really knew what it was I was doing. I wasn't the creator or the user of that database, and its tables and relationships are completely opaque to me (or they were - now I know how to look at them without fear of disaster).
I do find the more complex queries difficult to wrap my head around. Something about the terminology of right and left joins is unhelpful in constructing my mental model of what a query's results should be. The simple tables we set up for these assignments may not have the characteristics that would demonstrate the concepts best.
The handling of null values also stumps me a bit - I don't really understand what the consequences of having or not having a null value are, beyond perhaps triggering a 'must have data' condition. In my wee database experiment, null understanding also tangled with some misconception about how default values should work; these issues are probably the tip of the iceberg for continuing database research.
The really interesting thing is that I'm kind of looking forward to it. I would never have guessed that I'd find database work fun, once I was beyond GUI-based software tools that are supposed to make it less onerous. Maybe I just need to see the bones of a system before I'm happy.
This late, late post has been back-dated to keep things in order.
7.26.2010
7.19.2010
Navigating the ERD
I have a many-to-many problem. Apparently my gift for complicating relationships applies in more than one sphere; it took several readings of Prof. Fulton's warnings about avoiding overcomplication to rein in my database ambitions to the point where I can use it for these exercises.
That wild horse did get tamed, however, or at least hobbled. My wee webcomics database is just three tables with minimal attributes and I've been able to produce an ERD that looks sensible. It responded nicely to normalization and I think I'll be able to go forward with it for the next units.
That's fine for the exercises (I hope!), but it leaves me wanting. I perused a lot of ERDs for this unit, including many of the ridiculous number of examples at databaseanswers.org and I didn't see what I wanted - a way to diagram (and thus explain) the complicated relationship between creator, comic, and strip (instance of a comic) that comes from the common practice of doing cross-overs and guest strips.
I don't need to know how now, but it's a niggling question. I believe that I understand the ideas behind normalization, but I can't picture how to do it on this more complex structure - it's something that's just going to have be tried. I'd like to find a series of database design tutorials that are even more hands-on than the resources I've seen in class. And then I'd like to find the time to do them...
This late, late post has been back-dated to keep things in order.
That wild horse did get tamed, however, or at least hobbled. My wee webcomics database is just three tables with minimal attributes and I've been able to produce an ERD that looks sensible. It responded nicely to normalization and I think I'll be able to go forward with it for the next units.
That's fine for the exercises (I hope!), but it leaves me wanting. I perused a lot of ERDs for this unit, including many of the ridiculous number of examples at databaseanswers.org and I didn't see what I wanted - a way to diagram (and thus explain) the complicated relationship between creator, comic, and strip (instance of a comic) that comes from the common practice of doing cross-overs and guest strips.
I don't need to know how now, but it's a niggling question. I believe that I understand the ideas behind normalization, but I can't picture how to do it on this more complex structure - it's something that's just going to have be tried. I'd like to find a series of database design tutorials that are even more hands-on than the resources I've seen in class. And then I'd like to find the time to do them...
This late, late post has been back-dated to keep things in order.
7.12.2010
Technology planning is my bugbear
Well, maybe not technology planning itself - as far as I'm aware, I've never participated in an actual technology plan (although, interestingly, I've experienced everything listed in the What Went Wrong article anyway). This unit has proven to be a bugbear, though, in that I've been unable to effectively organize my thoughts and get the writing done.
Which is just what I'd expect to happen if I were drafted into writing a technology plan (see how I did that). I am very much one of this world's accidental technologists: the child of two IBM lifers who wanted to be an artist. I prefer things to stay organic and intuitive (translation: I don't like to put in the advance work, it's boring). I wonder how many tech plans have been written by people like me?
So it may not be surprising that one of my favorite pieces of wisdom from this unit's readings is to keep things open; don't write a plan that's so specific it boxes you in and leaves you with no place to go when things go wrong or just go different. Another, from Chabrow, is to fail fast. As long-serving state employee (no time off for good behavior), I've seen a lot of projects outlive their usefulness before they've even gotten off the ground.
If a technology planning process ever does come my way, I think I'll have a more thoughtful contribution to make. It will help that I'm making a list of the causes for project failure that come up multiple times in both the readings and on our discussion board; these are the real bugbears - poor needs assessment, scope creep, failure to bring the crew on board before setting sail.
This late, late post has been back-dated to keep things in order.
Which is just what I'd expect to happen if I were drafted into writing a technology plan (see how I did that). I am very much one of this world's accidental technologists: the child of two IBM lifers who wanted to be an artist. I prefer things to stay organic and intuitive (translation: I don't like to put in the advance work, it's boring). I wonder how many tech plans have been written by people like me?
So it may not be surprising that one of my favorite pieces of wisdom from this unit's readings is to keep things open; don't write a plan that's so specific it boxes you in and leaves you with no place to go when things go wrong or just go different. Another, from Chabrow, is to fail fast. As long-serving state employee (no time off for good behavior), I've seen a lot of projects outlive their usefulness before they've even gotten off the ground.
If a technology planning process ever does come my way, I think I'll have a more thoughtful contribution to make. It will help that I'm making a list of the causes for project failure that come up multiple times in both the readings and on our discussion board; these are the real bugbears - poor needs assessment, scope creep, failure to bring the crew on board before setting sail.
This late, late post has been back-dated to keep things in order.
7.05.2010
XMLovin' (part two of the series)
I was fortunate to have IRLS 672 follow on the heels of 515. Organization of Information, with Hong Cui, provided me with a hefty dose of XML recently enough that it's still doing me some good. One resource, of course, that I keep going back to is W3Schools. I can barely abide the layout and appearance of their site, however, and I root around for other tutorials. There's a lot on the web, but sometimes it's not particularly well organized. Google is many things, but it's not a proper index.
I'm a big fan of the O'Reilly books, which almost always have very proper indexes, and 'Learning XML' is available electronically through the ASU library. It's holding up well for its advanced age (a seven-year-old computer book is at least pushing 70 in dog years). On the day I start a serious XML project, 'XML in a Nutshell' will be on my desk.
I have to admit that I'm not very conscientious when it comes to tutorials. I learn by doing, and as soon as I've grasped enough of a subject to come up with a project or interest of my own, I'm off and skipping around, googling up a storm. It doesn't help me cover the material thoroughly, but what I do learn sticks.
I already scooped myself on practice system news in my previous post. It's time for me to admit that I've been working with my practice system all along, doing the exercises in parallel. I know just enough about OS installation and networking to have not gotten myself in trouble. I did have to re-burn the Ubuntu disk once, but other than that it's been smooth sailing all the way. I'm not building any character at all...and the gremlins are late to the party.
This late, late post has been back-dated to keep things in order.
I'm a big fan of the O'Reilly books, which almost always have very proper indexes, and 'Learning XML' is available electronically through the ASU library. It's holding up well for its advanced age (a seven-year-old computer book is at least pushing 70 in dog years). On the day I start a serious XML project, 'XML in a Nutshell' will be on my desk.
I have to admit that I'm not very conscientious when it comes to tutorials. I learn by doing, and as soon as I've grasped enough of a subject to come up with a project or interest of my own, I'm off and skipping around, googling up a storm. It doesn't help me cover the material thoroughly, but what I do learn sticks.
I already scooped myself on practice system news in my previous post. It's time for me to admit that I've been working with my practice system all along, doing the exercises in parallel. I know just enough about OS installation and networking to have not gotten myself in trouble. I did have to re-burn the Ubuntu disk once, but other than that it's been smooth sailing all the way. I'm not building any character at all...and the gremlins are late to the party.
This late, late post has been back-dated to keep things in order.
Subscribe to:
Posts (Atom)
