how to handle lots and lots of very similar tables

[eluser]jedd[/eluser]
Disclaimer - I'm reasonably clued in with PHP and programming in general. I'm not spectacular, but I border on competent. I don't have much OO understanding, but am working through a few books on the subject at the moment, and trying to apply this to a CI project. And, of course, I'm trying to learn CI at the same time. Love a challenge.

The Project - I'm creating a database that will include information about organisms, so this includes the full taxonomy of species, genus, family, etc. There's 23 of these suckers once you take into account subs and supers of the 'big 7', plus a few others. My DB schema at the moment has a relatively fat organism table, that includes columns for each of these taxa (yes, not terribly well normalised). For example:

Code:

CREATE TABLE organism  (
    id                  SERIAL,
    taxa_domain         bigint,
    taxa_kingdom        bigint,
     . . .  (19 others)
    taxa_subvariety     bigint,
    taxa_commonname     bigint,

Now, each of those taxa_* tables are properly normalised - tall and thin - and look like this:

Code:

CREATE TABLE taxa_species (
    id                  SERIAL,
    name                char(99) UNIQUE,
    description         char(200),
    INDEX (name),
    PRIMARY KEY (id)
    );

Now, I'm going to use the full MVC thing. I was about to create a template model file for handling each of those taxa tables, and replicate that across a bunch of files, then realised it's a pretty horrific thing to do for all the obvious reasons (maintenance, domino effect of code replication, etc).

So, I'm thinking abstraction - that's what they keep saying in these OO books. But how to do this and maintain the spirit of both OO and CI.

Right now I'm considering a (model) Taxa class, and the class includes a taxa type, which obviously determines which table gets hit with a query or update. But is that 'cool' to do it that way? I don't intend to use any kind of active record - though I did look at using the ActiveRecord Class for a while, then decided to do it a bit more 'raw'. Plus AR, as I understand it, is predicated on a class to table ratio of 1:1

It's tricky to work out what I actually want to know, but I think it includes:
o Is it kosher to handle multiple tables - even if they're related - in a single model class like this?
o Do you normally name a class differently if they're doing something special like this?
o Do you normally name model and controller classes to include the words 'model' and 'controller'? (I had a problem with my early experiments with AR where I wanted the names of both to be the same, but obviously they couldn't be.)
o Am I going to strike either very simple or very profound problems with the CI/OO way of doing things by having a class handle multiple tables - given I'm likely to eschew any kind of AR call.


I'm also having difficulty conceptualising how I'll handle multiple taxa objects given each one will refer to a different type of taxa, but will not be named to reflect which taxa they're talking about. I expect this will make more sense to me later, when I get to that bit, as each taxa component will be dealt with sequentially in my code.