Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python: Just Write SQL

joaodlf.com

Post reply on HN
Print view View original

281–288 of 288 posts

Re: Python: Just Write SQL

#281

Post by TX81Z »

aidos wrote: post #257
TX81Z wrote: post #236

Earlier quoted context omitted.

I’m sorry but 90% of the time I encounter somebody who swears by an ORM I’ll figure out the reason they use it is because they didn’t know SQL to start with and didn’t commit to learning a new language. The number of people who know SQL well and still choose an ORM seems to be very, very low in my experience.

Low, maybe, but we’re out there. Sqla just saves me so much time in general. Sometimes it’s easier to drop down a level, but for 99% of my db interactions the code will be significantly shorter using sqla, so I choose to use it.

Fair, I always figured there were some people in that bucket, just not that many!

I think I’m also just cranky over the general trend of junior devs who know a “framework” but none of the underlying concepts or code and can’t cope when their “framework” doesn’t…work.

Re: Python: Just Write SQL

#282

Post by TX81Z »

BeefWellington wrote: post #252
ubercore wrote: post #246

Earlier quoted context omitted.

When I've worked with datasets that size, the common operations tend towards the analytic or bulk operations, IME. That's not the sweet spot for an ORM, and SQL will often make a lot of sense. But, and again this is my experience, you often want to work with some more traditionally sized slice of that data, doing CRUDish things, and ORM can exist alongside the nicely tuned bulk or analytic operations. If you have the…

Yeah I agree here. If you're doing mostly transactional work then it can work for the 99%. As soon as you step towards analytics queries you start to see things fall apart and it's better to hand-tune your queries. In my recent projects that's essentially what I do - I use SQLAlchemy for very basic CRUD and then anything analytical gets handcrafted.

Doesn’t that increase complexity? I just have a database wrapper class and keep all my db code segregated there. In my case also using an ORM would blow up that segregated approach.

Re: Python: Just Write SQL

#283

Post by TX81Z »

hot_gril wrote: post #241
TX81Z wrote: post #239

Earlier quoted context omitted.

I think that’s part of why I’m having trouble with this framing - it’s treating CRUD as the entire universe of why you’d need to connect to a database. Some of us do very intense compute in very large datasets, and ORM are not capable in those tasks. At all.

Doesn't even have to get very intense. A simple timeseries schema gets slow/annoying quickly with an ORM.

I think for a lot of things an ORM is “good” at, you could likely just have a bunch of static JSON files and retrieve them from disk with zero practical difference.

I just can’t wrap my head around why you even *need* a database in those cases.

Re: Python: Just Write SQL

#284

Post by zzzeek »

aforwardslash wrote: post #273
zzzeek wrote: post #200

Earlier quoted context omitted.

yah I read Neward's thing, and it was one of the main reasons I wrote SQLAlchemy in the first place, because he was just so wrong. It read like he tried to write some object relational thing and it didn't work out, so he goes off and rant rant ORMs are wrong. Kind of proving that post wrong was one of the primary goals of SQLAlchemy, really, where I sought to change the question of "impedance mismatch" and "leaky abs…

> But if you are writing for 1200 tables Have you ever managed 1200 "live" (in-development) tables on a SqlAlchemy app? That is impressive. Not only because of the amount of work that entices, but also because you can just read the schema and provide a dynamic object representation of it (think dataclasses, but based on a table schema). Also, if you're querying 1200 tables, python might not be such a good idea. Imped…

Not personally but we absolutely have users dealing with 1000+ table databases . SQLAlchemy includes mass reflection and dynamic mapping features and there are also extensions like SQLACodeGen that generate mappings as python source code. Additionally, its not unreasonable that applications within an organization are composed such that they refer only to a particular segment of such a database, but across the organization there is source code that refers to the database as a whole in the aggregate.

Re: Python: Just Write SQL

#285

Post by tantaman »

specialist wrote: post #280
tantaman wrote: post #180

Earlier quoted context omitted.

I'm in a 4th camp: we should be writing our applications against a relational data model and _not_ marshaling query results into and out of Objects at all. Elaborations on this approach: - https://news.ycombinator.com/item?id=34948816 - https://github.com/papers-we-love/papers-we-love/blob/main/d... - https://riffle.systems/essays/prelude/

Nice share, thanks. I was never more productive than when using Access (and dBase II before that). Why can't we have that? My theory: Something was lost in the jump from workgroup computing to client/server. Imagine if Access was rebuilt on top of a client/server stack. That's kind of what Riffle is trying to do. I've been (slowly) working on the persistence stuff. It (mostly) moots the SQL vs ORM vs query builder sl…

> I was never more productive than when using Access (and dBase II before that).

I've never used access and have 0 familiarity with it. Are there any examples I could look at?

Re: Python: Just Write SQL

#286

Post by hot_gril »

TX81Z wrote: post #283
hot_gril wrote: post #241

Earlier quoted context omitted.

Doesn't even have to get very intense. A simple timeseries schema gets slow/annoying quickly with an ORM.

I think for a lot of things an ORM is “good” at, you could likely just have a bunch of static JSON files and retrieve them from disk with zero practical difference. I just can’t wrap my head around why you even *need* a database in those cases.

Honestly I wouldn't deal with JSON files on disk except as a last resort. Aside from convenience, you need a DB for transactional reads/writes. But you don't need an ORM for that anymore because Postgres and MySQL have json/jsonb types.

Re: Python: Just Write SQL

#287

Post by ubercore »

TX81Z wrote: post #282
BeefWellington wrote: post #252

Earlier quoted context omitted.

Yeah I agree here. If you're doing mostly transactional work then it can work for the 99%. As soon as you step towards analytics queries you start to see things fall apart and it's better to hand-tune your queries. In my recent projects that's essentially what I do - I use SQLAlchemy for very basic CRUD and then anything analytical gets handcrafted.

Doesn’t that increase complexity? I just have a database wrapper class and keep all my db code segregated there. In my case also using an ORM would blow up that segregated approach.

It's very very easy to keep the sql alongside models and other business logic. SqlAlchemy lets you drop down to fairly complex sql while remaining in Python, and will even take in a direct sql query as well.

The added complexity has always been a non-issue for me. Even a simple `sql.py` next to `models.py` works really well, for a pretty straightforward solution.

Re: Python: Just Write SQL

#288

Post by flow2kudo »

extasia wrote: post #4
ckdot wrote: post #3

Congrats, you just wrote your own ORM. Please mind that ORM doesn’t necessarily mean ActiveRecord, which could be considered an anti pattern.

What's Active Record and why is it an anti pattern?

Active Record is NOT anti pattern. It's just one of ways to get things done related to (relational) database and your application. Active Record, Data Mapper, Raw SQL or whetever has its pros and cons.
Post reply on HN