> An ORM attempts to store your data in an object oriented format This one right here, officer!

02:55 "We simply can't" well ... yes ... you can

1:05 I don't get it. So you present an inheritance problem, argue that RDBs can't into inheritance and say that ORMs are bad because of it?.. And then what, how does pure SQL deal with the problem better? Are you implying OO-languages and ORMs can't function without creating inheritance trees in your models? Also, I'm not a fan of single table inheritance, but you could have at least mentioned it.

4:01 this is actually absurd How would a no-ORM world look like and how exactly would this problem be any different? You know nothing stops you from writing a transaction using an ORM, right?

I think an important aspect / advantage of ORMs is type safety, not having to worry about the underlying schema, incredible ease of use and the possibility to pass data around the system without creating data classes additionally to the raw sql queries

False statements: 0:03 ORM are an attempt to make SQL obsolete 0:20 its a abstraction some people use to not learn sql 0:30 cherry picks bad code to make a point 0:50 ORMs attempt to store data in OOP format (most do, but not all) 4:00 Most ORMs are not transctionally correct (idk what you even mean by that tbh, the example is just a skill issue of a developer not using transactions, which as you mentioned can be done in raw SQL)

I highly doubt all ORMs work as you describe it...

1. Create stored procedures 2. Call stored procedures It's that simple.

ORM have been misused for years due to improper knowledge of how to architecture an application. Once you start to apply an hexagonal architecture pattern, you can concentrate database access in your DBAL (typically in Repositories) and adapt your use of the DB, either by using the ORM Query Builder or by writing raw SQL queries. ORMs shine in how they allow to map relational data to objects. If you add CQRS and separate commands from reads, you can quickly realize how you don't need an ORM on the read side but mostly on the write side.

Honestly having been forced to use ORMs at work, and also having to migrate between databases (for bad reasons, don't ask); when moving between databases, you WILL find inconsistencies in ORMs where they handle a migration set just fine in one db, but utterly fail on another engine

All of the example at 0:31 are awful because of the code, the languages and the libraries themselves, not because of the concept of an ORM. Show these to any developer using Rails and ActiveRecord, which actually has functionality and readable queries (even in shema migrations lul), they'll laugh. For example, you don't need to .include(x => x.stuff).then_include(y => y.more_stuff), (if I understood correctly what the code does), you can do .includes(stuff: [:more_stuff, :even_more_stuff]) Whatever god awful madness is on the second screenshot isn't how anyone ever would write production code, this is for seeds/tests at best, and even then you would create each type of record in a separate statement and put them into variables to reuse in the next.

what is your opinion about EF core though? i learned sql before i stared using ORM's which allowed me to actually check how good the queries are it generates and its actually a pretty complete and performant ORM. (as long as you dont do stupid things ofcourse, but bad code can be written in any language)

Thanks for this video. You raised very good points which has benefitted me immensely. Your video also led to a follow-up video by thePrimeGeon netflix guy. So thanks 😊

I can't remember the last time EVERY argument in a video was wrong, but this is it.

Totally BS video, ORMs could be pain in the ass that's true, but most of the statements are wrong if you just look at the documentation of any modern ORM

SQL alchemy is a pain in the ass. Not because of it, but how people uses it to avoid learning or use SQL.

PLEASE DO NOT USE THIS VIDEO FOR LEARNING; the author got so many points wrong. First: ORMs do not intend to make SQL obsolete. Most of the assumptions the author made and some of the examples are just oversimplifications, wrong or miss the point. E.g. SELECT * example just shows that the author has not really spent time exploring different ORMs for different languages; I know at least 2 ORMs for nodejs which invalidate that argument without any discussion. The transactional stuff is just completely wrong. At the end mostly the pro arguments remain which makes the conclusion just weird (connection pooling is not even something that is exclusive to ORM but mostly depends on the individual db driver). I recommend that the author reads the article "OrmHate" by Martin Fowler.

You don't need to go hog wild on orms, a simple class that does a query and maps the result to an object is fine 99% of the time. That usually makes it trivial to copy/paste that gnarly dba query you don't understand, etc. The trouble is when you start trying to do joins and relationships 'magically'. Your updates/inserts should be as tactical as possible, not just 'throw an object graph at it and hope dirty checking works'. Sure, it'll work great in your PoC, but 3-4 years in it needs a rewrite.

I don't see the need to use ORM because even the basic mysqli offers parametized queries that escapes strings for security.

2:50 why are you using a "NOT LIKE" clause with a literal string instead of a pattern? It is semantically equivalent to the simpler "!=" clause unless there's something funky going on with your db engine. Same with the later "LIKE" clause. What is the point of this?

You need to know sql anyways .Orm is great tool , if u have complex queries you will debug thus anyways and put some optimisation , ORM does not matter here. SQL != ORM . SQL BUILDER != Object Relational Mapping . Author lacks understanding this. You can write sql and use ORM to populate items.

EF Core is my bae

There is a fourth, superior option: ORM with a Query Builder like TypeORM does it. I have done a ton of complex queries, that would be simply impossible with other ORMs and a pain in the ass to implement with raw dogging SQL.

Appreciate the video! Great stuff! I've mainly been using Prisma but there are times when a SQL query needed, and you can execute so-called "raw queries" within Prisma using SQL, but these tend to be limited to one-liners only (unless I'm mistaken), so there are definite limitations here. Your video also brought to my attention how ORMs select all data from a table, which seems hugely inefficient.

Meanwhile where I work they rawdog sql while never setting up relational constraints (foreign keys are never specified as such), be amazed by 20+ year old java codebases.

0:16 Brazil referenced

I just ask GPT to build my SQL queries. Solves all the issues (if you know enough about what you want it to do)

I had to learn the lesson of this video the hard way, I can fully agree with about everything said. Just leave database logic in the database, do not try to re-create or abstract it within your application using some kind of ORM. As stated, you also usually don't change the DBMS and if you do you'll most likely find out that ORM didn't really help because new issues will arise left and right and soon enough you'll be debugging deep into the ORM sources to figure out what is handled how and how to change your code to work arround it. Just treat your database like a webservice that exposes a certain API. So just design stored procedures for your needs and consider to return XML for complex queries. You can easily work with XML in your application and don't have to worry about database internals. You can even create XML schemas as part of your API definition. That said for simple mapping purpuses from one more or less flat object to table for store and retrieval, a ORM might be indeed a good option.

1) The OO impedance[sic] problem you mention between ~0:55 and ~1:40 can probably be somewhat alleviated by building a sensible table structure in the DB first, some views on top of that, and only then importing these data structures into whatever programming language you're working with. Something like: create table person as person_id integer autoincrement primary key, -- or "generated by sequence" first_name varchar(50), last_name varchar(50), birth_date date, ... ; create table student as student_id integer autoincrement primary key, -- or "generated by sequence" person_id integer unique foreign key refers to person.person_id, university varchar(50), course varchar(50), ... ; create table graduate_student as graduate_student_id integer autoincrement primary key, -- or "generated by sequence" student_id integer unique foreign key refers to student.student_id, -- person_id integer unique foreign key refers to person.person_id, -- Maybe? Probably unnecessary. degree varchar(50), num_publications integer, ... ; create view persons as select p.person_id, p.first_name, p.last_name, p.birth_date, ... -- s.student_id, -- Maybe? Probably unnecessary. s.person_id, s.university, s.course, ... -- g.graduate_student_id, -- Maybe? Probably unnecessary. g.degree, g.num_publications, ... from person p join student s on s.person_id = p.person_id join graduate_student g on g.student_id = s.student_id -- or possibly g.person_id = p.person_id ; Then link the Person object in your code to that view, not the table(s). Will work fine for reading, and for writing if your DBMS supports insertable / updatable views. If it doesn't, inserting becomes a little hairier, having to insert into the three tables separately. 2) A nice compromise is the Delphi (and Free Pascal / Lazarus)[*] system with "raw" TTable and TQuery classes that expose table rows / query cursors as objects with (sub-object) fields. It exposes the DB structures as they are, but makes for easy communication with your own classes, so you can handle objects as objects and tables as tables. 3) As for your riddle at 4:15-4:24, at first I thought it might be something to do with the hard-coded "VALUES(1,", "VALUES(2,", and "where id=1", since that will only work once and is pretty weird. But, sure if the id isn't autoincrement / generated by sequence, it will work (once!), so not strictly speaking a bug, I suppose... So it has to be the double quotes around "hello", which makes that a column name reference in stead of a character-string value. (Though I think some RDBMSes might allow that. If nothing else, PROC SQL in SAS probably does.) --- [*]: Mentioning WTF I'm talking about, so people won't think I'm talking about every programming language in the world. See how easy that is, fsckwits?

Bunch of butt hurt ORM users in the comments.

I'm on the fence on whether to like or not. Here, have a comment maybe it helps w the algos.

wtf are you talking about. most of the arguments are silly.

Sorry for the bad audio y'all. Been sick for a while but couldn't put this off anymore, got so bored not doing anything. Really bad smacking, if someone has any tips on how to resolve it for future videos I'd be very grateful :D

World should be greatfull that you share your panifull exprience and wisdom with humanity. Not all will take your advices seriously, many will argue or give you names but some they they will know.

Ooof. Bad developers need to stop making youtube videos.

ORM is something bad that happened to IT. It hould be used only for prototyping and proof of concept projects.

I actually came to the same conclusion on my own. I built my own little dynamic DNS client and from the start everyone was saying use an ORM at least on the surface. I went through what no where I'm does and I said what the F*** do I need this for I'll just write things directly in SQL as at the end of the day all my data is going to be ending up in SQL And sure enough festival did not disappoint. Very happy with my app BH. Thanks for releasing this video though and letting others know.