(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!
No comments:
Post a Comment