Recently I've realized, those two are doing almost the same job, except that ORM additionaly "allows you to establish relations between those objects". (not to mention nice features like soft delete). These relations, if I have read the documentation carefully are slighty similar to what MariaDB/MySQL triggers (InnoDB) are doing - am I right?
If I'm establishing relations using the MariaDB triggers, and don't need features like soft delete - do I need ORM at all?
What are the advantages of each and when should I prefer one over the other?
Lucas, If I can understand correctly, ORM is a technique used to "see" a database as a class (in OOP); On the other hand, CRUD is a term to refer to the Create, Read Update and Delete operations. But the latter are just functions to manipulate any data you want.
If you combine ORM and CRUD you have a way to manipulate the databases as if it were a POO class, it is very simple method to work.
For example, if you want "create" an person on database without use ORM, you can use CRUD method with a query:
public function create(){ $name = 'Lucas';
//Here you can connect to DB engine and
$sql = "INSERT INTO people_table (name) VALUES $name;";
//And execute this query }
but with ORM, you have a Class_People that refer to people_table, and you can do
public function create(){ $name = 'Lucas';
$people = new Class_People; $people->name = $name; $people->save(); }
and with this way, you have additionaly encapsulation and inherit properties
Both the ORM and Model_Crud (a pour-mans-ORM without relations) are not designed to be query builders, for that use the DB class inside your model methods.
Having said that, you can just pass your selection in the array:
$result = MyModel::find(array(
'select' => array('id', 'name', verified'),
'where' => array(
array('id', '>', 10),
).
'order_by' => array(
'name' => 'ASC',
),
));
(disclaimer: from the top of my head, I never use Model_Crud).
Regarding relations, as in my opinion using ORM while using MySQL/MariaDB foreign keys doesn't really makes much sense. Because both can collide.
Consider the following situation:
tableA is related with the tableB using the MySQL foreign key(s) [delete, update -> cascade]
Now, If we do $tableBItem->delete(); ORM will attempt to delete tableAItem as well, which will end up with errors, since MySQL foreign key already did the same job.
Of course, we don't have to set ORM relations, but then, isn't it's just as said poor-mans-Model_CRUD in general?
The ORM (at least recent versions) are compatible with that, because the ORM works the other way, it will delete child objects before parent objects,
The main power of an ORM, besides the fact you use the data in an object manner, is that it automates joins for you, which with complex relationships can become quite complex as well. It can also do data transformations (like string to int, serialized to array, etc), event actions. etc.
The ORM is also platform agnostic, which means you can develop on your own system with MySQL, while the production app runs on Oracle.
Whether or not you need or want all that depends on you and your personal circumstances. Usually, in a business context is pays to use the ORM, as it saves time developing and maintaining an application, and time == money.
Donate
