Re:The Next 50 Years of Databases (2015)
by sanderjd on Tuesday November 12, 2019 @12:21AM
(#21511734)
This would definitely lead to me being very confused when things I'm selecting that I thought were aggregates were actually being implicitly grouped, or when one thing I'm selecting that I didn't realize is an aggregation results in grouping by all the other fields. There is no way for the query engine to know which direction I made a mistake in, so it just tells me something is wrong and let's me figure out how to fix it. Failing fast is much better than trying to guess at what I'm trying to do.
[ Parent
| on HN ]
Re:The Next 50 Years of Databases (2015)
by paulddraper on Tuesday November 12, 2019 @04:56PM
(#21518603)
To summarize: "Writing things twice allows you to know where you went wrong and correct it."
That's true.
I still prefer DRY, but I can appreciate the WET perspective.
Re:The Next 50 Years of Databases (2015)
by sanderjd on Wednesday November 13, 2019 @01:31PM
(#21527618)
Your summary is wrong. When you write "select field" you are saying which field to return from the query. When you write "group by field", you are saying that you want the query to group by that field when generating query results. You are not writing anything twice, you are writing two different things.
Re:The Next 50 Years of Databases (2015)
by paulddraper on Wednesday November 13, 2019 @04:16PM
(#21529663)
When I write "select field" I am saying which field I want to return from the query and which field I want to group by. There's no difference. And the DBMS enforces that there is no difference. *
* Except for the special case when it's non-aggregated and I want duplicate rows in the result set. SQL allowing duplicate rows is a departure from the underlying relational paradigm.