Archived RedBeanPHP is the easiest way to do ORM in PHP. Does not require a single line of configuration. (redbeanphp.com)
submitted ago by llagerlof
Posted by: llagerlof
Posting time: 5.5 years ago on
Last edit time: never edited.
Archived on: 2/12/2017 1:51:00 AM
Views: 576
SCP: 2
2 upvotes, 0 downvotes (100% upvoted it)
Archived RedBeanPHP is the easiest way to do ORM in PHP. Does not require a single line of configuration. (redbeanphp.com)
submitted ago by llagerlof
view the rest of the comments →
[–] Synes_Godt_Om ago
It's an old post by now but to get some discussion going here. I'll respond with my 2c.
The question is not silly at all.
The most obvious reason to use an ORM over PDO directly is to be able to make changes to queries programatically, and, of course, the mythical idea of being database agnostic (which in my view is just that, a myth).
It could be the right way to go if you are a company where maintaining application code is more convenient than maintaining SQL, or put another way you may find application devs cheaper, easier to come by than db admins. This, however has two consequences that may or may not be desirable: 1) your use of the underlying database has to be much more simplistic than it potentially could be and 2) advanced features, data quality and data integrity now is the responsibility of the application (and its devs) rather than the database.
The potential (and in my experience actual) drawback is that ORM developers don't fully understand all the databases they claim to support. In the PHP world in particular this means that the purpose of an ORM in reality becomes dumbing every database down to the level of MySql because that's the only database the devs tend to know well. Though nothing inherently wrong with MySql, a database like PostgreSQL, has a lot of advanced features that are not supported by any ORM - or is a HUGE pain to try to replicate with an ORM. Thus using an ORM to access Postgres would almost automatically lead to not using any of Postgres' advanced features (like JSONB, CTE, materialized views, window functions etc.).
I personally do use an ORM for a very limited set of operations because the framework I use (phalcon) has a built-in ORM that makes these specific operations easy while making them harder not using he ORM (I am looking into ways to remove this too). Except for those operations I use PDO for everything. I store all my queries in YAML files that are loaded in the DI container as an array of named queries. This way all queries are kept the same place and are easy to administer and easy to access everywhere I need them.
[–] Foobarbaz ago
I agree entirely. I could use my example of migrating from SQLite -> MySQL as a trivial example. "I'd like a column that stores int please." -- "uhh, how large are we talking here?". SQLite won't care whereas MySQL does care. SQLServer is where my main experience is so this has been an enlightening task so far. An ORM may make a "smart" decision for you behind your back and you'll be none the wiser. This burnt me with SubSonic once BADLY. What happens when you fill a TableNameHere.Delete(VariableWithAListOfPrimaryKeysToDelete) where that variable is an empty List<t>? IT DELETES THE ENTIRE TABLE. Lessons learned that day, my friend, lessons learned.
Interesting you should bring up PostgreSQL. I chose MySQL over it only because of mixed opinions and I was more familiar with it. I keep being told it's better in nearly every way "except" and I'm mainly a SQL Server guy so I suppose I got spoiled without having to think or choose.
Looking at phalcon -- I see they use a 'use' command that I've never seen in PHP before (to give context, I think my last experience with PHP was ~ php 4.1? 4.2? It was a long time ago?) -- so I may be out of the loop and perhaps I should get a book and instead walk in as a beginner.
I had assumed PDO was really close to an ORM but it appears that assumption quite clearly wrong. It seems to merely be a sanity checker plus a Strongly Typed wrapper -- which is what I thought an ORM was. I seem wrong on that one. I have much to learn it seems.
I appreciate your response -- it's basically told me I need to let go of my old knowledge and start anew and then figure out what old knowledge I have is useful.
[–] Synes_Godt_Om ago (edited ago)
That's probably one of the greatest understatements you've made in a long time ;-). PHP has since turned into a real and modern programming language with actual OOP and real namespacing, powerful, mature frameworks like zend2, symfony, Phalcon and many others.
The only way Postgres may have a disadvantage on paper compared to Mysql is in a multi-master setup. Postgres has that but only as an extension. In all other areas it shines out of the box, in particular when it comes to data consistency and standards compliance and it has all or most of the advanced features you find in sqlserver and oracle and a few of its own. The documentation is the best bar none. And compared to oracle it has one very particular advantage: its price structure is totally transparent.