Why use an ORM in PHP?

问题:

I recently start studying ORM, a question jumped to my mind:

PHP applications use mostly MySql and Sqlite, almost all PHP servers have that installed, so is it worth to use ORM in PHP to be database-indipendent?

What about performance?

回答1:

database independence is not the main reason for using an ORM. what you want to have is a general abstraction of the database. this might imply: simplicity of use, faster development, database independence, ... in any case, usually it's worth using an ORM. if your application sucks up all your cpu power, then you might use some plain sql to optimize certain queries. I guess this is a rare case, though.

you might want to read this: What are the advantages of using an ORM?

回答2:

There are several reasons you might choose to use an ORM, a few I can think of:

• Most ORMs will enable you to validate data for INSERTs and UPDATEs.
• ORMs will let you map column names in the db to working field names in your db. Which can be handy if you're working with a database that someone else designed and has strange column names.
• They will also handle relationships nicely for you too. (eg if you fetch a row which has a 1:m relationship on one of the columns you would get a subarray of the related items without having to manually do another query).

Most of the reasons for using an ORM relate to speed/ease of development.

In terms of performance, I've used doctrine with php before and hydration created a huge overhead compared to just fetching the rows.

回答3:

For database independence (and performance) use PDO. It's built in, its prepared statements are great for preventing SQL-injection vulnerabilities.

If you're stuck on O/RM, it even comes with a little OO-flair... See PDOStatement::fetch (and some of the other fetchXxx methods).

回答4:

ORM is kinda waste of time. Which is wierd, since it was designed to save you time :) but it is true. I had the oporrunity to use ORM in several languages and it isn't worth it. There are basically 2 types of projects:

1. Simple projcets with few tables (sometimes even 1 table), no authentication etc., lets say just simple standalone tables

2. Complex projects with many connected tables, views and other stuff. Possibly more databases as well.

   1. Yea feel free to use ORM if your familiar with setup and how to use it its peace of cake, but you never know if project requirements change and you end up regreting you ever stepped on ORM field :)
   2. Dont use ORM since you will spend more time fixing the "auto generated" stuff wich ORM provides. I believe some ORMs are quite advanced nowadays but ORM is here like (wild guess) 10 years (actually I believe its much more)? And it is obvious its kinda dead end. It is not gonna replace the standard way in the future, today trend is NOSQL databases ect.

In my opinion ORM is alive only thanks to frameworks which use it internally. And performance? I am not sure (since I dont use it anymore) but I believe performance could be a problem too. You have to pay at least some price for the fact that you are abstracted from database query right? I think ORM was great idea on paper but it just doesnt work well.

回答5:

Using an ORM alleviates the redundancy of writing boilerplate code related to opening a database connection, pooling connections, preparing a statement, executing the statement, mapping the results of executing the statement to something more meaningful, and lastly closing the connection.

It's much cleaner to do something like instantiate an object, set its properties then invoke a save operation on the object. This kind of value alone is worth using an ORM over manually coding the many steps required to interact with a database.

Also, with the a clean ORM it is possible to swap databases with minimal change to the application.

Hope that helps.

回答6:

What if your server runs PostgreSql, or SQL Server - two other very common database engines.

What if you want to connect to a legacy database?

Also, have you ever maintained any large projects that connect directly to the database? It makes me shiver when I open up a file full of mysql_query calls.

Performance-wise... Depends on the ORM in question. I'm more familiar with them in a .NET setting, and certainly in that environment there is a wide variance in performance, but this is usually a trade-off with features.

Using an ORM will increase the orthogonality between your code and the database - this will make it easier to develop and maintain. The ability to switch between databases is a benefit of this, but certainly not the sole reason.