I wish the SQL standard would add some basic syntax sugar, such as support for trailing commas and allowing use of aliases in more places.
SQL language proposal: JOIN FOREIGN
51–60 of 206 posts
Re: SQL language proposal: JOIN FOREIGN
#52What I really need is something like: SELECT -col1, -col14 FROM table LIMIT 50; Where the minus sign means I don't want these two columns. I still don't see a way to do it easily (for Vertica and in Datagrip).
Similarly, I'd love some form of GROUP BY every column except for It feels silly when you are SELECTing a ton of columns, then you add a JOIN to a many-to-one relationship which you want to aggregate. Now you need to either make it a subquery (and hope the optimizer doesn't screw up) or duplicate all your SELECT expression (not even the identifiers) into the GROUP BY.
Queries like this won’t break but will silently fail upstream by missing data if column names change or are deleted. The explicit nature of SQL ensures that it will break positively which is a better type of failure in my opinion.
Re: SQL language proposal: JOIN FOREIGN
#53Personally, I think SQLs verbose syntax is a good thing, and increases clarity/interpretability. It reduces cognitive load to have things explicitly listed out. Not having the table and column names in the query itself makes it much harder to read and understand queries without prior knowledge of the data model.
FWIW we do have `NATURAL JOIN` already, which is a lot worse than this proposal.
Re: SQL language proposal: JOIN FOREIGN
#54>This improved in SQL-92: Did it?
Yes, I think so, at least according to: https://learnsql.com/blog/history-of-sql-standards/
What makes you think otherwise?
Re: SQL language proposal: JOIN FOREIGN
#55What I really need is something like: SELECT -col1, -col14 FROM table LIMIT 50; Where the minus sign means I don't want these two columns. I still don't see a way to do it easily (for Vertica and in Datagrip).
R's data.table has that.
dt[1:50, -c('col1', 'col14')]
Re: SQL language proposal: JOIN FOREIGN
#56tangent question - what're some effective ways to learn how to write SQL?
Re: SQL language proposal: JOIN FOREIGN
#57What I really need is something like: SELECT -col1, -col14 FROM table LIMIT 50; Where the minus sign means I don't want these two columns. I still don't see a way to do it easily (for Vertica and in Datagrip).
That's very close to SELECT *, which has it's own dangers.
I agree that it would be nice for exploration and testing, but probably should not be used in production.
Re: SQL language proposal: JOIN FOREIGN
#58[deleted]
Re: SQL language proposal: JOIN FOREIGN
#59Personally, I think SQLs verbose syntax is a good thing, and increases clarity/interpretability. It reduces cognitive load to have things explicitly listed out. Not having the table and column names in the query itself makes it much harder to read and understand queries without prior knowledge of the data model.
FWIW we do have `NATURAL JOIN` already, which is a lot worse than this proposal.
NATURAL JOIN is great because it's like a relational AND. How else will you join with Table Dee and Table Dum? https://twitter.com/benjiweber/status/1476629550608101384
It's just risky if you don't design your schema with relational algebra in mind.
Re: SQL language proposal: JOIN FOREIGN
#60Earlier quoted context omitted.
Similarly, I'd love some form of GROUP BY every column except for It feels silly when you are SELECTing a ton of columns, then you add a JOIN to a many-to-one relationship which you want to aggregate. Now you need to either make it a subquery (and hope the optimizer doesn't screw up) or duplicate all your SELECT expression (not even the identifiers) into the GROUP BY.
Queries like this won’t break but will silently fail upstream by missing data if column names change or are deleted. The explicit nature of SQL ensures that it will break positively which is a better type of failure in my opinion.
[deleted]