Live data from Hacker News

Does OLAP Need an ORM

clickhouse.com

11–20 of 52 posts

Re: Does OLAP Need an ORM

#11
post #8
post #6

My take is... No one needs an ORM: https://dev.to/cies/the-case-against-orms-5bh4 The article opens with "ORMs have proven to be useful for many developers" -- I believe the opposite is true.

I think what I just really want is a language that treats sql as a "first class" component in the same way perl treats regexes. The devil is of course in the details, but it's a nice dream.

Not quite first class citizen, but you might like sqlx. At least it embraces the idea that writing SQL directly is in fact a good idea and helps you to do so safely.

https://docs.rs/sqlx/latest/sqlx/

Re: Does OLAP Need an ORM

#12
post #6

My take is... No one needs an ORM: https://dev.to/cies/the-case-against-orms-5bh4 The article opens with "ORMs have proven to be useful for many developers" -- I believe the opposite is true.

I agree with this as well. I started my career at the height of ORMs. Most software developers were only learning the ORM APIs (which of course all differed significantly) and very few were learning SQL outside of the bare basics.

ORMs, like all abstractions, are a leaky abstraction. But I would argue because of the ubiquity and utility of SQL itself they are a very leaky one where eventually you are going to need to work around them.

After switching to just using SQL in all situations I found my life got a lot simpler. Performance also improved as most ORMs (Rails in particular) are not very well implemented from a performance standpoint, even for very simple use cases.

I can not recommend enough that people skip the ORM entirely.

Re: Does OLAP Need an ORM

#13
post #6

My take is... No one needs an ORM: https://dev.to/cies/the-case-against-orms-5bh4 The article opens with "ORMs have proven to be useful for many developers" -- I believe the opposite is true.

How do you convert your type-safe native objects to and from the database in a reusable way? If you do anything in a reusable way, you're 95% of the way to an ORM. Or do you just accept that you get back random dictionaries from the database and don't care about type-safety?

Re: Does OLAP Need an ORM

#14
post #6

My take is... No one needs an ORM: https://dev.to/cies/the-case-against-orms-5bh4 The article opens with "ORMs have proven to be useful for many developers" -- I believe the opposite is true.

Is the proposition in the OP not pretty much what you're suggesting in your blog? They're currently not using the query builder syntax, instead its pretty much "improving on SQL as strings" with a bunch of the other ORM-like benefits (type safety, autocomplete, etc.)

Perhaps saying "ORM" is a bit of a misnomer, but they're discussing the DX ergonomics of an ORM and acknowledging the exact challenges you describe

Re: Does OLAP Need an ORM

#15
post #6

My take is... No one needs an ORM: https://dev.to/cies/the-case-against-orms-5bh4 The article opens with "ORMs have proven to be useful for many developers" -- I believe the opposite is true.

How do you convert your type-safe native objects to and from the database in a reusable way? If you do anything in a reusable way, you're 95% of the way to an ORM. Or do you just accept that you get back random dictionaries from the database and don't care about type-safety?

You write INSERT and SELECT statements for the object types you want to persist.

What is your concern re: random types popping up? SQLite springs to mind as a prime offender due to not enforcing column types OOTB, but most dialects have rather strong typing.

If we’re talking about mapping UUIDs and datetimes from their DB representations to types defined by the language stdlib, that’s usually the responsibility of the DB driver, no?

Re: Does OLAP Need an ORM

#16
The reasoning behind yes, it would help is in building data tools for people. So you load up your parque files with data, ingest it into your platform, it uses clickhouse (or some OLAP) for tabulation of data, the platform presents a UI that allows the data engineer to select which fields, etc.

This can only be achieved by utilizing some sort of type system. Whether it's reflecting on the tables, codegen on the fly, or having to write custom adapters for each structure. All of which can be greatly simplified with an ORM.

It's not going to help much with bespoke report asks from the business though.

Re: Does OLAP Need an ORM

#17
post #8
post #6

My take is... No one needs an ORM: https://dev.to/cies/the-case-against-orms-5bh4 The article opens with "ORMs have proven to be useful for many developers" -- I believe the opposite is true.

I think what I just really want is a language that treats sql as a "first class" component in the same way perl treats regexes. The devil is of course in the details, but it's a nice dream.

LINQ? Just throwing it out there; obviously not everybody can or wants to run a C#/.NET stack, but entity framework (core) is about as close as you can get to the perl and regex integration. I think Ruby on Rails gets there too, but I'm not a RoR guy, so I can't comment.

Re: Does OLAP Need an ORM

#19
post #6

My take is... No one needs an ORM: https://dev.to/cies/the-case-against-orms-5bh4 The article opens with "ORMs have proven to be useful for many developers" -- I believe the opposite is true.

This really depends on the quality of the ORM. I used to write Java software, and Hibernate with QueryDSL saved me probably _months_ of typing. And I dare say, produced much nicer-looking code.

And for most of the code, the performance and overheads were negligible. C# with LINQ is even better, it provides strong typecheck for the queries and often has almost zero overhead.

I'm using Go now, and I don't even want to touch any of the available ORMs because they all suck, compared to the state-of-the-art in Java circa 20 years ago.

Re: Does OLAP Need an ORM

#20
> Borrow the best core concepts:

Schemas as application code means you get version control, PR review and type‑safe changes. A query builder that feels like SQL and lets you write “real” ClickHouse queries with IDE autocompletion and compile‑time checking. Local development and CI should mirror production so you can preview schema changes before they apply to prod.

>>>

I believe this is what dbt set out to accomplish. They came at the problem from the point of view of a data transformation language that is essentially a pseudo type checked SQL for analytical engines with some additional batteries included (ie macros) but the motivation was similar. I’ve always felt that what has held dbt back from more mainstream adoption by the dev community is because they’ve prioritized data transformation over data access to the application layer - ie business intelligence tools over a web app.

Moosestack looks interesting- will definitely check it out.

Post reply on HN