> Well that works great in OO, but how to model that to a relational DB? > Obviously putting all the extra stats for a Pitcher in the Player table > would fail the test for 2NF. So how would you lay it out? I'm debating > having a table for Positions that just has an identity(the primary key) > and a position name. The Player table would then have a foreign key > constraint that has to match one of the keys in the Positions table. That > way, if the Position for a player was ever "pitcher", then I know there > should be a corresponding entry in the Pitcher table that lists the extra > data. > > But this just doesn't feel clean to me. Any suggestions or links/books > anyone can point me to?
True, it's not "clean." RDBMS's just aren't designed for OO. Try googling for "Object-Relational Mapping". This is the concept of an abstraction layer between objects and relational databases, and you'll get a plethora of articles and tools on the subject. There is a class of object-oriented databases (OODBMS) which have their own query language and other standards, but I don't really know much about them.
