The necessity of ORM implementation of PHP database

In fact, learning new things and some of the "tall on" concept, but I have always been the most concerned about only one point: I can not use the project, what is the use of this thing, what is the benefit, what is the price?

Many on the web say that object-oriented database operations can decouple the Model layer directly, without needing to care how it is implemented, and can use OOP, such as GetXXX (), to get a field value for a record.

In fact, I have always wanted to make a travel notes website (similar to Baidu travel/Hornet's Nest), directory structure also in http://segmentfault.com/q/1010000002890348 proposed, midway also because saw a lot of IoC article is a headache, It is found that the project size is difficult to reflect its advantages, but is to increase the burden of design and design. Layering has made the action as concise as possible, and the Model can do a good job of reuse.

1, really do not know why more and more use ORM it? Is it because of the need for object-oriented programming (too general)? Or does my query result object be cached? If the amount of website access is large, is it the final solution to cache the query results in object form? Is the KV-based NoSQL also an alternative? What about the cache of the database itself?

2, in fact, decoupling is really not the most concerned about the problem (self-think has not reached the point of decoupling, the above layering has been pretty good), ORM Builder is also drunk, as the direct Model to write SQL statements to the happy, in the future to replace the database directly rewrite (do not worry about this problem, This time), the sense of performance and reuse has been a bit of a contradiction, that aside the need for multiplexing and decoupling, if the use of ORM is not because of the object cache revenue?

3, also before the company brother said do not use join, directly nested query, I said that is not the Assumption article page 15 article has the author information, I will run 15 times the post table, halfway run 15 times the user table? He said the results of the query can be cached, not quite clear whether the cache is a database-level or Model object level?

Not a comment, thank you for your answer!

Reply content:

In fact, learning new things and some of the "tall on" concept, but I have always been the most concerned about only one point: I can not use the project, what is the use of this thing, what is the benefit, what is the price?

Many on the web say that object-oriented database operations can decouple the Model layer directly, without needing to care how it is implemented, and can use OOP, such as GetXXX (), to get a field value for a record.

In fact, I have always wanted to make a travel notes website (similar to Baidu travel/Hornet's Nest), directory structure also in http://segmentfault.com/q/1010000002890348 proposed, midway also because saw a lot of IoC article is a headache, It is found that the project size is difficult to reflect its advantages, but is to increase the burden of design and design. Layering has made the action as concise as possible, and the Model can do a good job of reuse.

1, really do not know why more and more use ORM it? Is it because of the need for object-oriented programming (too general)? Or does my query result object be cached? If the amount of website access is large, is it the final solution to cache the query results in object form? Is the KV-based NoSQL also an alternative? What about the cache of the database itself?

2, in fact, decoupling is really not the most concerned about the problem (self-think has not reached the point of decoupling, the above layering has been pretty good), ORM Builder is also drunk, as the direct Model to write SQL statements to the happy, in the future to replace the database directly rewrite (do not worry about this problem, This time), the sense of performance and reuse has been a bit of a contradiction, that aside the need for multiplexing and decoupling, if the use of ORM is not because of the object cache revenue?

3, also before the company brother said do not use join, directly nested query, I said that is not the Assumption article page 15 article has the author information, I will run 15 times the post table, halfway run 15 times the user table? He said the results of the query can be cached, not quite clear whether the cache is a database-level or Model object level?

Not a comment, thank you for your answer!

If you have 10 or even 5 small partners to write SQL, today this person joins 3 tables tomorrow the man wrote a subquery, the day after the other person batch update where condition misspelled, and then on average every day 3 times because the field name error caused by the bug, you know the ORM is valuable

We have also encountered the same problem recently, ORM performance is really much lower than native SQL, ORM only suitable, fast agile iterative development.

ORM performance is really going to degrade, so it depends on how you choose-if you want to get your site up and going quickly, ORM can be faster, especially if you have code-generation tools like zii.

Don ' t fall in the trap of premature optimalization
Find bottleneck constraints. is the key. Don't dwell on the efficiency of a certain part.

Recommend a short and short ActiveRecord library, Lloydzhou/activerecord GitHub can achieve the effect of relation like yii. Document Address: http://lloydzhou.github.io/activerecord/

class User extends ActiveRecord{  public $table = 'user';  public $primaryKey = 'id';  public $relations = array(    'contacts' => array(self::HAS_MANY, 'Contact', 'user_id')  );}class Contact extends ActiveRecord{}$user = new User();// find one uservar_dump($user->notnull('id')->orderby('id desc')->find());echo "\nContact of User # {$user->id}\n";// get contacts by using relation://   'contacts' => array(self::HAS_MANY, 'Contact', 'user_id'),var_dump($user->contacts);

Using SQL means that you cannot change the library because SQL is not universal.
Using join means that your project can only be in one library, and the join cross-Library is more complex.
Small projects do not need to use ORM, as you said, not bad time, change.

But the big project is not the same, to divide the library, to change the library, today with MySQL tomorrow may use hbase may also be mixed with.

Model level Other

