how to handle lots and lots of very similar tables

[eluser]TheFuzzy0ne[/eluser]
[quote author="jedd" date="1235451120"]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).[/quote]

My advice is not to be too concerned about code replication to begin with. Get on with the implementation, and your understanding of your application will develop with the application, and you can always tighten things up at a later date.

[quote author="jedd" date="1235451120"]
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.
[/quote]

Why not just create your model as a library, and extend/override it?

[quote author="jedd" date="1235451120"]
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[/quote]

Nonsense! If that was the case, there would be no $this->db->join(), would there? You are free to create a model however you want to, however, a model usually represents a table or group of tables that are dependant on one another in some way. For example, you could have a forum model, but you'd never get a forum into a single table.

[quote author="jedd" date="1235451120"]
o Is it kosher to handle multiple tables - even if they're related - in a single model class like this?[/quote]

Yes, of course!

[quote author="jedd" date="1235451120"]
o Do you normally name a class differently if they're doing something special like this?
[/quote]

Nope. Just ensure the name is relevant to what the class does. My forum model is named - wait for it... Forum_model

[quote author="jedd" date="1235451120"]
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.)
[/quote]

I wouldn't recommend it with controllers, as it would be included in your URI, and would look a bit silly.

There's nothing saying you have to do that with models, libraries or anything else, although I find it can help when you're using the objects. Also, let's say you had a controller called "Test", you wouldn't be able to have a model called "Test" too; they wouldn't be able to co-exist, so Test_model is the obvious name for the model. If you want, you can rename your model when it's instantiated by passing a second parameter to the loader. You can call you model Bob if you want, it's just not very descriptive.

[quote author="jedd" date="1235451120"]
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.
[/quote]

I'm not sure if anyone can answer that. It all depends on how you structure your code.

[quote author="jedd" date="1235451120"]
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.[/quote]

I'm not exactly sure how many methods you'll need for each taxa table. You might be able to get them all into a single model (perhaps called "Taxa_model", but then again, you may choose to break them down into individual models.

Hope this helps.