Welcome Guest, Not a member yet? Register   Sign In
how to handle lots and lots of very similar tables
#1

[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.
#2

[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? Smile 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.
#3

[eluser]jedd[/eluser]
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.

Okay. I had actually started to think I should just build 3 or 4 taxa tables, and treat them separately .. just so I can start moving on. I just fear that I'll never 'get back to' things later on. (Does anyone ever? Wink

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

Forgive my obtuseness .. and note that I've only read thru the Library part of the user_guide twice just now .. but what advantages would this have over, say, keeping this logic in a model? Libraries appear to be called by Controllers only, but I don't see that as a problem.

With the AR stuff - I was sure that I'd read that each class maps to its own table, but perhaps that was a specific AR extension rather than the built-in CI stuff. But, okay, good - very happy to hear I won't get disowned by the CI deities if I wrap up a couple of dozen table front-ends into one model!

Stupidly, I hadn't connected controller names with URI segments, but, yes, of course. <slaps forehead> I'll stick with _model suffixes then. Part of the confusion I've given myself in the past, and it's pretty arbitrary, has been with my IDE (Quanta) - as I toggle between tabbed files where the filenames in those tabs are very similar.

Quote:Hope this helps.

Very much so - thank you!
#4

[eluser]TheFuzzy0ne[/eluser]
[quote author="jedd" date="1235460528"]
Forgive my obtuseness .. and note that I've only read thru the Library part of the user_guide twice just now .. but what advantages would this have over, say, keeping this logic in a model? [/quote]

That's what you would be doing, but your model would extend the library. Smile The library would serve almost as an abstract class. In fact, if you really wanted to, the library could be your abstract class.

[quote author="jedd" date="1235460528"]
Stupidly, I hadn't connected controller names with URI segments, but, yes, of course. <slaps forehead> I'll stick with _model suffixes then. Part of the confusion I've given myself in the past, and it's pretty arbitrary, has been with my IDE (Quanta) - as I toggle between tabbed files where the filenames in those tabs are very similar.[/quote]

I know that feeling. I used to lose track of which tab was what file all the time... I use Aptana for my IDE. Sadly, it doesn't support multiple rows of tabs like Quanta, but it does allow you to rearrange tabs (I can't remember if Quanta does or not). The beauty of this is I can arrange identically named tabs into the fairly obvious order of Model, View, then Controller. Wink Aptana mucks this up though if you have more tabs in the tab row than you can fit. If you don't mind a little bit of slow clunkiness, I'd highly recommend Apatana. It's Java-based, which is why I think it's so slow. It's not as fast as Quanta at loading/saving files and switching tabs, but other than that, it's fantastic.
#5

[eluser]jedd[/eluser]
Okay .. I'll probably keep this stuff, as you recommended, in separate models for the moment, and maybe look at abstracting it later (once I get my head around that idea) into a library. Ahhh .. later on!

I'm working on a pretty rinky-dinky computer (MSI Wind) so not a lot of CPU or screen space to allocate to java / clunky interfaces, but I've just downloaded aptana and will have a look-see. And no, you can't re-arrange tabs in quanta - one of the few problems I have with it as an IDE - but I suspect aptana/eclipse's performance will keep me coming back to it (Quanta).




Theme © iAndrew 2016 - Forum software by © MyBB