Hi,
I'm working on a project, that will serve a lot of requests, due to it's nature. I'm wondering will it be a good idea to use an ORM a which pattern to use: ActiveRecord (e.g. Doctrine) or Row/Table Data Gateway (e.g. Zend_Db_Table).
The third variant is using stored procedures, but they will slow down the development process.
Maybe using them for only some of the tasks would be a good idea.
Any thoughts will be much appreciated.
Regards,
Emil Ivanov
Faster ORM
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
This is a really confusing subject for me because these the patterns seem to be mixes of the same parts and actual implementations often pick one of the patterns and then customizes it until it is unrecognizable.
The essential parts of these patterns are the same though.
- What is essentially a Value Object that represents the database row.
- A Finder that does the query based on constraints.
- A Gateway that wraps the SQL for the selects, updates, inserts and deletes.
An additional related part is a Mapper that adds a layer of flexibility between the structure of the object and the structure of the database table. That mapping can be used for convenience or to deal with changing schema.
You question was which would be best suited for "a lot of requests". I don't think any of them are necessarily better or worse at that. Perhaps adding a mapping layer may effect performance, but if well designed is would not. If writing highly tuned SQL is your goal then Gateway or Model classes would be good a separating out the SQL from the program logic and providing a central place for you SQL guru to do tuning.
The essential parts of these patterns are the same though.
- What is essentially a Value Object that represents the database row.
- A Finder that does the query based on constraints.
- A Gateway that wraps the SQL for the selects, updates, inserts and deletes.
An additional related part is a Mapper that adds a layer of flexibility between the structure of the object and the structure of the database table. That mapping can be used for convenience or to deal with changing schema.
You question was which would be best suited for "a lot of requests". I don't think any of them are necessarily better or worse at that. Perhaps adding a mapping layer may effect performance, but if well designed is would not. If writing highly tuned SQL is your goal then Gateway or Model classes would be good a separating out the SQL from the program logic and providing a central place for you SQL guru to do tuning.
(#10850)
Having developed several sites in the last 8 years which required the handling of 10's to 100's of millions of requests per month, I can say from vast experience that the database is almost always your first choke point. That is of course if you are even halfway decent at writing efficient non-db related code.
I personally write table based models to handle all my db and modelling logic. I write my SQL by hand and include any model based logic inside the model classes. After a while you learn how to write very flexible and very efficient models without having to write a lot of SQL.
Because of this, I've never really seen the increased speed in development time that many ORMs promise. In fact, I've spent more time trying to map models than it took me to just write a few flexible SQL handling methods. And I used to be a Java programmer. Try mapping models with J2EE some time. That makes these PHP ORMs look like childs play.
And I know my application code runs faster than the ORMs because I don't have their overhead (even though it's not much in many cases). I'm never stuck fighting the ORM trying to optimize a SQL call and I never worry about having to modify both the model maps AND the customized SQL you may end up having to write when you lose the fight with your ORM.
Is my strategy right for everyone? Of course not. I like to get down to the lowest level and architect my own frameworks to save ME development time. Write classes that simplify and accelerate the things that bog ME down. While at the same time, never having to worry about performance problems do to feature bloat overhead or inefficient procedures.
I guess the point I'm trying to make is, "Different strokes for different folks". You should let time and experience be your greatest influence on your programming style. Try out the ORMs on something simple. And try writing your own models on something simple. Find out what saves YOU time and what ends up being a pain in the neck for YOU.
Good luck.
I personally write table based models to handle all my db and modelling logic. I write my SQL by hand and include any model based logic inside the model classes. After a while you learn how to write very flexible and very efficient models without having to write a lot of SQL.
Because of this, I've never really seen the increased speed in development time that many ORMs promise. In fact, I've spent more time trying to map models than it took me to just write a few flexible SQL handling methods. And I used to be a Java programmer. Try mapping models with J2EE some time. That makes these PHP ORMs look like childs play.
And I know my application code runs faster than the ORMs because I don't have their overhead (even though it's not much in many cases). I'm never stuck fighting the ORM trying to optimize a SQL call and I never worry about having to modify both the model maps AND the customized SQL you may end up having to write when you lose the fight with your ORM.
Is my strategy right for everyone? Of course not. I like to get down to the lowest level and architect my own frameworks to save ME development time. Write classes that simplify and accelerate the things that bog ME down. While at the same time, never having to worry about performance problems do to feature bloat overhead or inefficient procedures.
I guess the point I'm trying to make is, "Different strokes for different folks". You should let time and experience be your greatest influence on your programming style. Try out the ORMs on something simple. And try writing your own models on something simple. Find out what saves YOU time and what ends up being a pain in the neck for YOU.
Good luck.
Yes, your biggest fallback will be the database and queries. Write optimal queries, and have the correct indexes on your tables.
From a code point of view, if you can do it procedurally, I'm all for that. Nothing is faster than just straight coding. Most people on here will probably disagree with me though.
From a code point of view, if you can do it procedurally, I'm all for that. Nothing is faster than just straight coding. Most people on here will probably disagree with me though.
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
Thanks a lot for your answers.
Now, I personally prefer writing SPs, but that can be slow (very slow some times). So I want to speed up development a bit, but for this project, performance will be very important. I can say I'm quite good at SQL, optimizing queries etc... (I used to be an .NET/MSSQL dev).
Currently, I'm developing a project with Zend_Db_Table, and it does speeds up developing time.
Probably it's the better solution than Doctrine.
I'm still very uncertain, but I think I'm going to go with sps. I wrote a (simple) class, that calls stored procedures, as they are php functions and obtains the results (if any) in one line (I love neat solutions
).
Please, share any other thoughts you might have.
Best regards,
Emil Ivanov
Now, I personally prefer writing SPs, but that can be slow (very slow some times). So I want to speed up development a bit, but for this project, performance will be very important. I can say I'm quite good at SQL, optimizing queries etc... (I used to be an .NET/MSSQL dev).
Currently, I'm developing a project with Zend_Db_Table, and it does speeds up developing time.
Probably it's the better solution than Doctrine.
I'm still very uncertain, but I think I'm going to go with sps. I wrote a (simple) class, that calls stored procedures, as they are php functions and obtains the results (if any) in one line (I love neat solutions
Please, share any other thoughts you might have.
Best regards,
Emil Ivanov