Re^2: Design help: OO Perl and db tables

[j3]

Right -- and I think my class hierarchy does a good job of keeping common qualities in base classes. For example, Car might have a get_transmission_type method, since that's common to all cars. FastCar might have a get_turbo_type method, since, in my limited world, only fast cars have turbos. :)

But now, in my cadillacs and nash_ramblers database tables, do I put string fields/columns in *both* of those tables for transmission_type and turbo_type? Or is it more customary to create a transmission_types table, and a turbo_types table, and have foreign keys in the cadillacs and nash_ramblers tables that refer to those other tables? What if there's only 4 different transmission types? What if one car has an "UltraSpin" turbo and another has an "Ultra-spin" one?

Continuing, my two fast cars have an awful lot in common with each other (corresponding to all the attributes they inherit from FastCar and Car). So, at some point, you can go overboard in pulling out every little attribute into its own table. You could end up with cadillacs and nash_ramblers full of almost nothing but foreign keys. (Hm... well, items with floating values, like fuel_level (no pun intended) would still be a regular value and not a foreign key...)

I'm starting to think that the common practice might be to use the classes at the bottom of your inheritance hierarchy as models for your db tables, and *then* pull out common data into its own tables when it ``makes sense to do so''. I'd be curious to hear if this is what other folks do, and if they have any rules of thumb about how to figure when it makes sense to pull data out into a new table.

Edit: After re-reading Edward's advice (above), I see that, in the above example, even though you might only have a handful of transmission types, you probably still would want to have a table for them, rather than putting lots of strings in your tables for something that would fit nicely into an additional table (same goes for turbo types). Thank you.