[eluser]boltsabre[/eluser]
I think a lot of people use 1 table per model because the documentation/examples are often set out like this.\
When they designed CI (or any other MVC framework for that matter) they had absolutely NO idea what business application/logic you would use it for and they tend to promote to use 1 model for one table. That's good for some projects, but not for others. See below.
I tend to group models by "use cases". For example I have a model which handles blacklisting of forum posts, users by id/email, and ip addresses. In there I have interaction with my forum tables, user table/s, and blacklist table.
I could have made it more modular and divided it into three models, but why? I know in my case (it's a personal website) that this approach will be fine for now and in the medium term. In the long term, perhaps I will need to change it, but if you try to future proof everything you just end up making more work for yourself. Making code that "may" handle something in the future is a pretty big code smell to me.
So, as far as I am concerned it all comes down to an application by application approach. What works for me may not work for you. What you have to do is have a good idea of what model functions you need, and where they will be called. Once you have a good general overview of the application it should become pretty obvious what will work best for you.
Good luck with it.
