If you were about to start a medium-sized #PHP project, what would you choose as an #ORM, and why? It should be something stable and well maintained. If the business takes off, then there should be no need to replace that layer.
Caveat: imagine that Doctrine and Eloquent haven't been invented yet.
Did you know that many Django newcomers get confused between null=True and blank=True?
With over 1000 upvotes, this is one of the most popular StackOverflow questions on Django.
Here I try to demystify blanks and nulls: https://youtube.com/shorts/2BgoCIYkT4c?feature=shared
La page wikipedia qui liste les #ORM (object relational mapping) précise en commentaire :
"Only place entries here that are links to actual Wikipedia articles about notable object–relational mapping software. External links, redlinks, non-notable sites will be removed. If you have questions, use the talk page."
I use ORMs like Eloquent for CUD and very simple R, but custom queries for any complex R. It always executes quicker and returns more memory-efficient results. If I want instances of the first page of results’ objects, I select just those IDs and get models back. #php#eloquent#orm
Are you sure that you want to power your astronomical telescopes with electricity that has such high carbon intensity? #ORM#GTC#CTA#LaPalma#ClimateEmergency
Entity Framework Core, or any ORM for that matter, can be magic, madness and maybe even a sin. Come to my workshop so your following project is not your next mistake. I'll show you incredible things, leave you breathless (and without scars), possibly screaming and crying.
If the ecosystem you're writing #code in doesn't have a #database#ORM, and you don't want to write and maintain an ORM, you are doomed to poorly recreate an ORM.
People wonder why I like ORMs even when they're unnecessary. Firstly, I've never liked SQL. I think that writing queries to a RDBMS is something that a computer should do, akin to compilation. In the few times when extreme optimization is warranted, low level code can be generated to suit that specific case. In other times, ORMs usually provide a more natural interface to data that increases readability and code flow.
ORMs can be helpful for rapid development, but as projects grow and evolve, they can become a double-edged sword. Dependencies, #performance bottlenecks, and loss of control over #SQL optimizations can hinder mature projects. Striking the right balance between abstraction and direct #database interaction is crucial.
What is your favorite #Python#ORM for #SQL and #SQLite? I am currently looking for an ORM judt to sinplify my implementation.
I am considering going for SQLite because the writes and reads are low, and the total size will also be a few 100 records, but I want the strengths of SQL. Also, I am running it in #Docker, so it simplifies the deployment.
The biggest illusion about ORMs is the expectation that they require no SQL knowledge. In due time, you'll have to troubleshoot your ORM code at SQL level.
ORMs help bridging the object/relational gap. But you have to know both sides to successfully use this bridge.
So learn SQL first, then pick an ORM, a SQL builder, code generator, raw SQL, or whatever and write great DB-centric apps. But learn SQL first.