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:
intsome_func(char a, bool b, char *c);
And letting whoever has to read the code after you go look at the definition and figure out by themselves what any of that is supposed to mean.
Or naming your variables a, b, c, etc.
Aliases are meant to improve readability imo, not worsen it.
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 bI’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.cityWell, in this case
aandbare 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 namedusers_who_won_the_company_lottery(intentionally bad name) then aliasing it asusersor even aswinnerswill be nice, even necessary, and you do not have to ask "What the fuck iswinners?For me, although I have seen a lot of people do this in SQL in real scenarios, using
aandbin 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:int some_func(char a, bool b, char *c);And letting whoever has to read the code after you go look at the definition and figure out by themselves what any of that is supposed to mean.
Or naming your variables
a,b,c, etc.Aliases are meant to improve readability imo, not worsen it.