Re: Under what circumstances should one use a non-equijoin?

Thanks Mark, Brian, and Jonathan.

Mark - nope, no exam. I'm revisiting the fundamentals of relational database design, Descartesian style, to help tackle some particularly vexing db design problems. I keep going round in circles trying to capture a particlar set of data that has a lot of variability.

I'm performing a lot of tabular gymnastics in my design, and the # of tables keeps growing. This indicates to me that I need to revisit the fundamentals of relational database theory and design. And also, perhaps, to see if inheritance and objects are the answer.

That said, if y'all could have everyone out there read only two books on relational database design - one beginner book and one advanced book - which would these be? Preferably ones with few math formulas, as I'm looking for theory tied to practice.

And if there was one, preferably small, beginner's book on object-relational design, which would that be? I realize that object-relational hasn't much caught on, but it may be the only answer to my design woes.

Can anyone cite a use case where it simply doesn't make good sense to design a relational database vs. an object-relational database? Surely someone else out there has performed enough design backflips to realize that relational isn't always the way to go.

Again, I wonder if my intuition to go the inheritance route will turn out to be correct, or if its based on my lack of deep understanding of relational database theory and design.

Also wonder if I need a database design "extreme makeover" - which in my case would be a simplification of what I'm already doing.

Thoreau famously wrote "Simplify, simplify, simplify!" And I'd be inclined to comply if only I knew how.

Help!

Thanks very much.

Dana Received on Fri Jun 02 2006 - 06:04:37 CDT