The key you are missing is the idea of a "hasMany", "hasOne",
"hasAndBelongsToMany", "belongsTo", and the other conventions.
With that many of the joins are automagically created for you and you
generally dont need to worry about your bindings are they will happen
unless you tell them not to.
I think its about more to using ActiveRecord than just that record
itself, its about how the row is encapsulating other logic which
saves you time and work from figuring out.
I just browsed through the CI docs @ http://www.codeigniter.com/
user_guide/database/active_record.html and (no offense) have to say
that I really can't see what you get out of it, even the chaining
part ...
$this->db->select('title')->from('mytable')->where('id', $id)->limit
(10, 20);
(ehh looks like straight SQL to me ;-)
So it looks like you would have to join and do all the work vs. say
Cake where you would stick w/ a convention and have it all wrapped up
for you.
(BTW, anyone correct me if Im wrong since I too am trying to explore
what the pros/cons of other frameworks are).
- Jon
On May 11, 2007, at 1:56 PM, Joseph Crawford wrote:
Guys,
We are using CodeIgniter for our framework that will run our sites,
however the database implementation that they offer is based on the
Active Record pattern. I have been running into issues that are
making me think this is not the pattern for us to use.
I have been going through the php|arch guide to php design patterns
and I believe that we would be better off with the Data Mapper
Pattern.
All of these patterns bring up a concern with me though. They are
stating that each class should be related to one table. We have
things setup like this.
Tables
Content
JobPostings
Articles
Reviews
etc. Each of the tables have an entry in the Content table since they
all share Content in common. Currently we have the Active Record
pattern and our models extend a base Content model.
So for example our job postings would be like this
http://jobs.ere.net/job/3431/
It will call the JobPostings model with the $this->jobs->load(3431);
which will load the job info, which then in turn calls
parent:load(3431); which will load the content for that particular
job. I could do this in one join query and there are other times
where it would make more sense such as when grabbing multiple
locations for a JobPosting, etc.
My question is how can you join tables and still stick to the patterns
that I am reading about? Does joining tables completely bypass the
reason for using these patterns?
I am not asking how to do a join, i know how to do that ;) I just
would like some insight on the best practice when it comes to using
these patterns.
Any insight would be greatly appreciated.
--
Joseph Crawford Jr.
Zend Certified Engineer
Codebowl Solutions, Inc.
http://www.codebowl.com/
Blog: http://www.josephcrawford.com/
1-802-671-2021
[EMAIL PROTECTED]
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
