If there's an activity in computer programming that separates the men from the boys, it's recursion and hierarchies. Recursion is such a simple and elegant thing, but so mind-bending that it takes a while to feel comfortable with it. Functional recursion, a method which calls itself, is something that I find easy to understand. If a method is a request for an action, that action makes a request for itself. It's not so hard to follow. Recursion is a natural thing when you're talking about methods in a class.
However, recursion gets goofy is when you force it to go where it doesn't belong. That's right, I'm talking about relational databases. A table of data is inherently not a good structure for storing hierarchical data. Sure, it's easy enough to make a table join to itself. But, in order to pull out the data, you've got to know ahead of time how many joins to use. And with each subsequent join, performance degrades. That, and making the queries to get information about a tree of data can get nasty. Until now, I thought that this was the only means of organizing hierarchical data in a relational database. Fortunately, I was wrong.
Tonight I set out to figure out how else I might be able to represent a hierarchical data set in a relational database. To my delight, I found an answer that I like. Nested sets can be used to store hierarchical data. Although, it's slightly confusing, especially when you talk about adding and deleting new nodes, and double especially confusing when you start thinking about sorting those nodes. I've got an idea for a project where this kind of stuff is going to be essential. I'm excited to find that someone has done the research to figure out the right way to do this stuff.
Sunday, April 16, 2006
Data in the 3rd dimension
Posted by Eric at 12:49 AM 0 comments
Tuesday, April 04, 2006
Crib with a built in legacy
I have the good fortune of being the son of a talented and very generous carpenter. My Dad built a gorgeous crib for my soon-to-be-son. Shana and I are so excited about it!
As my father tells me, it's constructed out of wood from trees that his father cut down. After it was cut down, my grandfather had it rough sawn and stored it in the rafters of the barn. My dad actually remembers playing on top of the stack of timber when he was a child. I'm happy to say that at least one more Rank child will have the opportunity to play amidst the same wood.
Posted by Eric at 11:02 PM 0 comments
Sunday, April 02, 2006
What do I know?
That's a rhetorical question, of course.
I had a thought this past week that I wanted to share with you all. To me it's quite a powerful thing to keep in mind when I'm communicating with others. It's simply this
It is better to have an informed opinion than to have the answer.
An informed opinion allows you to improve upon it. As an opinion becomes more informed, the sharper its focus becomes. Having the answer can leave you blind sided by something you didn't see. This has happened to me time and again. I'm just now seeing it from this perspective.
I'm finding that if I want to make my conversations with others productive, it's better to have beliefs, founded in good evidence and experience, than it is to have cast an answer in concrete. Such answers can bring you to your knees when you find out that the evidence out there doesn't support your beliefs. However, if you take the position that you're only doing your best to inform your beliefs, so that you can make the right decisions, life is better. People will actually want to talk to you because you are open to communicating ideas back and forth.
It may be simple, but it's helpful to me to know this:
I only know what I believe, and I only believe what I have good reason to believe. And from my experience, I've good reason to believe that I can be certain about nothing. Take that paradox and munch on it for a while.
Posted by Eric at 11:22 PM 0 comments