I present to you a php framework with an "orm" that doesnt support table joins. Yes, you heard it right.

I just want to say few things to the developers community -
If you are a bad programmer, please spend your time at improving rather than writing frameworks, or making the stupid decision on using SUCH SHIT FRAMEWORK AT A CORPORATE COMPANY!

Also if you are not sure if you are a good programmer or not, chances are you aren't. That's just how it is.

"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.)

ORM without joins.

I need more coffee!

ORM without joins sounds like csv with extra steps.

They 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...”

"It makes your application more complex than it should be"

Complex... like.... useful?

https://fatfreeframework.com/3.7/...

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