I've used Django with "real data", as in accountancy software for multiple years of transactions across 200+ fairly large clients and it's absolutely fine.
Whereas I've used Sqlalchemy and getting it to do a basic join, turns out there's 3 different ways of doing it all with an insane amount of crap to find the right way of doing things. I actually left my old job in part due to Sqlalchemy being too painful to work with.
Re:Migrating to SQLAlchemy 2.0
by BiteCode_dev on Thursday February 18, 2021 @04:00PM
(#26185440)
There is absolutely a lack of a decent SQLA tutorial for IRL code.
The doc is very formal, and if you want to make a website, a quick script or a data migration, you are left on your own to find the proper setup.
Re:Migrating to SQLAlchemy 2.0
by WesleyJohnson on Thursday February 18, 2021 @07:08PM
(#26187681)
I use Django with "real data" as well and, generally, it's pretty good once you learn how to wield it. My biggest issues are lack of multi-column primary keys and inefficient queries when doing .count(), that often introduce unnecessary group by statements in the subquery. If either of those could be addressed, I'd enjoy it so much more.
Like... Query.join(),
https://docs.sqlalchemy.org/en/13/orm/tutorial.html#querying... .
Django is optimizing for the 99.99% of people rather than the 0.01% of people who manage billions of rows on a single table. I like SQLAchemy, but for most people the added cost of managing connections, transactions, have to decide whether to use the 'ORM' or not, manually having to 'commit' changes, eager-loading vs. lazy-loading, is a complete waste of time if all they want is a website that will be used by - at best - a couple hundred people concurrently.
I caution people against using Django because the ORM makes so many weak, simplified assumptions about how a database works that don't bear out in practice. It's fine for a blog. It falls apart when you're working with Real Data.