If performance is important, then don 't use an ORM. You are just gonna get yourself into trouble.
A good midway solution could be to use an ORM for your backoffice, but to use simple queries for your frontend. Take this into account when desiging your tables. Suppose a product has a limited lifespan like so PRODUCT - id - name - date_from - date_until Then I would split this into two tables for the frontend like so: PRODUCT - id - name - alive (boolean indicates whether a product should be visible or not) and PRODUCT_LIFE - product_id - date_from - date_until The point is that you really don 't need the date columns in your frontend, only easy and fast selection is important. So you will use an tinyint that is indexed so that selection is blazingly fast on your frontend. This will complicate things on the backend, but this is something that can be handled with subforms and doctrine. But again, I wouldn 't recommend an ORM for the frontend. You could do the same for other functionality and limit your actual product table to the fields that are actually necessary in the frontend. James On 3 jul, 13:23, Cyrille37 <[email protected]> wrote: > Hello, > For a special project performance is more important than Orm > functionnalies, but I would like to use an Orm. > I found on google some benchmark that show Propel really faster than > Doctrine. But perhaps those Benchs are old and deprecated, I do not > know. > > Do you have experiences about performances diff betwen Propel (last > version) and Doctrine (last version) ?? > > Thanks > Cyrille. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
