wrote:
> So, the reason we do not use "find" very often are both legacy (for me) and
> practical.
> Before I joined the company they were using an outsourcing team that
> developed the most of the project. The login used to be VERY slow and the
> engineer hired before of me found that the "find"s on the user at login
> time, were performing a few hundred of queries. So he decide to go around
> using pure SQL.
>
> I went through some of the source code of CakePHP but I admit that I did
> not touch the ORM part at all. I am looking to our code right now. We have
> a lot of queries that have to (left and inner) join 10+ tables ( I can see
> a few with 11 and one with 12). There are a few problems about using
> CakePHP ORM:
>
> 1) You hide to the developer the tables that you are going to use. First of
> all in these case it is not so clear to know what the recursive number is
> going to be. You still need to have the database schema in front of you.
>
> 2) It does not seem that the ORM give you a lot of control on how a query
> is resolved.
>
> 3) CakePHP does not seem to do just one query but a few of them increasing
> the time to get a result to unacceptable levels. The user table for example
> is linked with at least 30 tables (probably more). Some of these
> relationships are one to many. Some of the queries need to go 3-4 levels
> deeper. It is absolute madness to think that is Ok having cake making 200+
> queries when you can get the result with one query. I read some complains
> in some articles that were criticizing CakePHP's ORM comparing it to the
> Ruby's one (that is still not the fastest). Maybe things can be done
> better. If you have an application serving 200 users that are not too
> demanding maybe it is Ok running 200+ queries in a find in a controller and
> having the users sometimes wait for 10+ seconds to the system to respond.
> But when the number of users increase to 10K+ and 100K+ nobody would be
> able to use the system. Furthermore to deliver a good user experience, you
> usually need to give an answer to the user in <less than 200ms and with a
> SQL query well designed you can do that.
>
> So in the end to have more control on how the data is accessed and keep and
> acceptable speed we decided to use find only when it needs only one (rarely
> two) tables and they have maximum one relationship with other table.
>
> I would really like to use the ORM, and I was a strong support of using the
> ORM for everything but in practice it does not seem to scale well.
> Am I missing something here ?
Query has it's place, but everything you've said indicates your
appication is not using cake's orm as designed (login more than 1
query? doing it rong)
AD
--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php
No comments:
Post a Comment