Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
AlmondSauce14014228d"Also if you are not sure if you are a good programmer or not, chances are you aren't."
I've actually found the opposite to be true. Some of the best devs I know wouldn't really rate their skills that highly, and some of the most confident devs I know are also some of the worst.
(Those with false confidence are also the most likely to write crappy frameworks.)
C0D463675228dORM without joins.
I need more coffee!
AmbientTea842228dORM without joins sounds like csv with extra steps.
Root74649228dThey forgot the Relational part of Object Relational Mapper
So it isn’t an ORM. It’s just an OM. Or really, more of an “um...”
N00bPancakes7318228d"It makes your application more complex than it should be"
Complex... like.... useful?
Always include sources.
"Before you weave multiple objects together in your application to manipulate the underlying tables in your database, think about this: creating views to represent relationships and triggers to define object behavior in the database engine are more efficient. Relational database engines are designed to handle views, joined tables and triggers. They are not dumb data stores. Tables joined in a view will appear as a single table, and Fat-Free can auto-map a view just as well as a regular table. Replicating JOINs as relational objects in PHP is slower compared to the database engine's machine code, relational algebra and optimization logic. Besides, joining tables repeatedly in our application is a sure sign that the database design needs to be audited, and views considered an integral part of data retrieval. If a table cross-references data from another table frequently, consider normalizing your structures or creating a view instead. Then create a mapper object to auto-map that view. It's faster and requires less effort."
I don't disagree that polymorphic relations and OOP make an ORM hard.
But from experience - shoving every tidbit into the database and wondering why noone has a fucking clue what's going on in the diarrhea of views and tables (wordpress anyone?) is bad.
I was never a fan of views - and I mean fully materialized views - as it leads in most cases to very bad design choices.
SQL antipatterns should be a must read.
"If a table cross-references data from another table frequently, consider normalizing your structures"
And that part makes me worry.
There are limitations in databases. In most databases one index / table is the normal rule. Optimization can take it higher, but the conditions are very specific to use more than one index per table per query.
So cramming everything in one table and calling it normalized, nope
To the whole "Anti Join Gang" - please die