[eluser]jedd[/eluser]
[quote author="Jow272" date="1258915803"]
To explain what I want to do; I'm building a webapplication in which users can store a wide variaty of information. This means that user data is stored and with this user data of course also address data.
[/quote]
Happily this doesn't sound hugely left-field.
From what you describe .. well, I have a few ideas, but need more info. I'd suggest that some of the functions in your controller(s) that you want to call from elsewhere should be, themselves, relocated. They could reside in any of these places:
o MY_Controller - excellent for common functionality that's short, sharp and sweet
o library - excellent for stuff that you want from some, but not all, your controllers
o helpers - ideal for things that involve munging around with data but ideally don't required the $CI superobject / DB access
o models - yes, you have some already, but they aren't *just* for getting/setting database records
Okay, for instance, can you give a list of the controller function that you've got (cd application/controllers ; grep function * ) - that will provide a good insight, assuming you've used sensible names for your functions in there.
Alternatively you may just get away with having fewer, fatter controllers (though I suspect you'll still need to consolidate some functionality as per the above options).
Quote:The database for the application has for normalization reasons only one table for addresses.
Normalisation reasons are good reasons - in my v.minimal experience, a decently normalised (to 3NF) schema makes for cleaner model interfaces, though this may apply more to models that front several tables - rather than a 1-model-per-table arrangement. Oh, if you're using that approach, you might get some benefit from shifting several tables to be handled by one model - depends on your schema, and complexity of data accesses of course.
In any case, I think we can help you come up with a more elegant method than calling multiple instances of a controller.