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

OrmHate

martinfowler.com

Post reply on HN
Print view View original

131–136 of 136 posts

Re: OrmHate

#131

Post by Spooky23 »

sjwright wrote: post #98
Spooky23 wrote: post #46

Earlier quoted context omitted.

> In my admittedly anecdotal experience, I have found that ORMs are the most useful for the most trivial queries. For anything complicated, I find it easier to drop into SQL and write the query directly As a recovering DBA, I want to jump out of my seat and say "Yes, exactly!" In many situations, "simple" queries can easily cover 90% of what you actually need, and simple queries are often an order of magnitude less e…

> If your devs are in the habit of writing lots of SQL, > they'll often decide to do things like write one complex > query to avoid the need for a few trivial queries. As someone who single-handedly maintains a large codebase and a large database for a large website, I can assure you you've hit the nail on the head but completely missed the point. Unless you're writing a hello world style to-do list, trivial queries…

I agree with you too, which may sound strange, but I think the difference is in the teams. I think in your case (and many others), my position doesn't make sense. Why? Because you're competent and grok programming and databases, which is an amazingly rare. Also, you're working on a really small team.

In a bigger or more distributed team, you need to have strong standards and governance when many people are sharing one resource. Otherwise, you run into a "tragedy of the commons" scenario where the whole business suffers.

Re: OrmHate

#132

Post by MattRogish »

einhverfr wrote: post #129
xi wrote: post #120

Earlier quoted context omitted.

I was about to prepare the query without ties and yes it is a lot harder than necessary and, more important IMO, much less readable/intuitive for people than have to maintain the code and that is exactly why different SQL dialects introduced ORDER BY/LIMIT/OFFSET/TOP/RANK etc. Very good point. In the book pointed out by Matt, Date explicitly states he's not saying ORDER BY is not useful, just that it doesn't return a…

First I don't know why order by, limit, offset, or windowing functions, can't be said to return a relation if we define relations in a way which is sufficiently useful to include these operations. In other words, they are used in ways which returns sets of tuples (or sets of entities if you want to see it that way), based on specific selection criteria. I would thus agree that to the extent that these are not part of…

Relations being defined what they are is not accidental; sets are not bags and there are a lot of very good things that come out of a relation having a very well defined, uh, definition.

It's not a matter of "usefulness" but of "well-defined" that allows us to derive a whole lot of other interesting things.

Folks actually have defined ORDER BY, LIMIT, OFFSET, etc. in terms of the RM; it's just that the typical ORDER BY doesn't return a relation because of ordering (sets are unordered by definition) and so there was a lot of gymnastics they had to do in order to keep the set theory intact.

Sure, arbitrarily reordering is not a hard concept (or even implementation) but to make sure you cover all the bases requires a significant amount of work. A RDBMS is a complicated thing and you don't want to just add something to it without doing proper due diligence.

One could argue that NULLs are more "useful" (I disagree) but the addition of NULLs (a deceptively simple concept) has vastly overcomplicated SQL and lead to a number of inconsistencies in the spec.

Re: OrmHate

#133

Post by lucian1900 »

jerf wrote: post #56
mping wrote: post #40

Earlier quoted context omitted.

I strongly disagree with this. I'm consulting for a project where I cannot discuss technical decisions about database modelling; sometimes we need to query 20/30 tables or more in a tx, with very complicated mappings 5+ levels deep. If I was to write the sql for this, I'd take 10x the time and it would be wrong anyway. Of course, this is one end of the spectrum where the ORM just enable me to shoot in the foot faster…

"If I was to write the sql for this, I'd take 10x the time and it would be wrong anyway." SQL is the problem here. It's so hard to write reusable, composable fragments of SQL that we've all just internalized the idea that we have to write the query you're referring to from scratch every time, which is a bizarre and annoying intrusion of 1970s software engineering into our 2012 world. You almost certainly have pattern…

I've found tools like SQLAlchemy do let you compose queries pretty well.

I've been told ClojureQL has a similar property.

Re: OrmHate

#134

Post by einhverfr »

MattRogish wrote: post #132
einhverfr wrote: post #129

Earlier quoted context omitted.

First I don't know why order by, limit, offset, or windowing functions, can't be said to return a relation if we define relations in a way which is sufficiently useful to include these operations. In other words, they are used in ways which returns sets of tuples (or sets of entities if you want to see it that way), based on specific selection criteria. I would thus agree that to the extent that these are not part of…

Relations being defined what they are is not accidental; sets are not bags and there are a lot of very good things that come out of a relation having a very well defined, uh, definition. It's not a matter of "usefulness" but of "well-defined" that allows us to derive a whole lot of other interesting things. Folks actually have defined ORDER BY, LIMIT, OFFSET, etc. in terms of the RM; it's just that the typical ORDER…

Sets may be unordered by definition but that doesn't mean you can't define something interesting as an ordered set.

Consider the Pythagorean attempt to prove that all numbers were rational by trying to prove that the square root of two was rational. That they were able to prove that it was not rational meant that we ended up with a new category of numbers. Similarly once you get into the square root of -1 you get into yet another category of numbers designed to address that problem.

Our numeric model isn't complete with just rational numbers, or just rational and irrational numbers. Today we have to add imaginary and complex numbers as well. Why shouldn't we be expanding relational math in the same way?

Re: OrmHate

#135

Post by stevenwei »

einhverfr wrote: post #127
stevenwei wrote: post #126

Earlier quoted context omitted.

Good question. I can't speak for all ORMs, but both SQLAlchemy and Core Data provide direct support for self-referential relationships SQLAlchemy lets you drop down to raw SQL as well if you need to, while still taking care of mapping the result set to objects for you. Core Data is less powerful (and technically not an ORM), but it's the defacto standard on iOS so I'm pretty much stuck with it.

So if you have self-referential relationships of arbitrary depth then can it generate clauses like WITH RECURSIVE or CONNECT BY? Or are you functionally limited to one level of self-joins without dropping to SQL?

WITH RECURSIVE is supported in SQLAlchemy now, although the syntax is rather verbose. Not sure about CONNECT BY, I think you may need to drop to SQL for that.

Re: OrmHate

#136

Post by einhverfr »

stevenwei wrote: post #135
einhverfr wrote: post #127

Earlier quoted context omitted.

So if you have self-referential relationships of arbitrary depth then can it generate clauses like WITH RECURSIVE or CONNECT BY? Or are you functionally limited to one level of self-joins without dropping to SQL?

WITH RECURSIVE is supported in SQLAlchemy now, although the syntax is rather verbose. Not sure about CONNECT BY, I think you may need to drop to SQL for that.

that's pretty cool. (I would assume that since WITH RECURSIVE is the standard and CONNECT BY is Oracle's invention that either it would be handled by db-specific extensions or just be another cost of running Oracle)
Post reply on HN