446

Lucky enough, I am C++ Developer (feddit.org)

submitted 3 weeks ago by genfood@feddit.org to c/programmer_humor@programming.dev

119 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] jjjalljs@ttrpg.network 18 points 3 weeks ago* (last edited 3 weeks ago)

Personally I feel like SQL syntax is upside down, and things are used before they are defined.

SELECT 
a.id -- what the fuck is a?
, a.name
, b.city -- and b??
from users a -- oh 
join city b on a.id = b.user_id -- oh here's b

I'd expect it to instead be like

From users a
join city b on a.id = b.user_id
SELECT
a.id,
a.name,
b.city

[-] invictvs@lemmy.world 1 points 4 days ago

Well, in this case a and b are only aliases of table names, and it is assumed that tables were already "defined", i.e. they already exist. And aliases in my opinion are meant to shorten long table names, or give a name that will be more appropriate in the context of the query, considering more than tables names can be aliased, at least that's how I'm using them. But they still have to be descriptive enough so it's clear what kind of data we are working with without the need to look for what they are actually aliasing in advance. In your example if the table was named users_who_won_the_company_lottery (intentionally bad name) then aliasing it as users or even as winners will be nice, even necessary, and you do not have to ask "What the fuck is winners?

For me, although I have seen a lot of people do this in SQL in real scenarios, using a and b in SQL is not a bad practice, it's a terrible practice. Feels like using them in function declarations in other programming languages, like doing a function declaration in C, at the top of the file like that: