Every time I use it I feels like I’m going back to the 90s. No variables, no functions; Oh but you can do a CTE or subquery…👍
UNION ALL, UNION ALL, UNION ALL… “There’s got to be a better way, surely…”
looks up better way
“Oh, what the fuck?!.. Nope, this will just be quicker…” UNION ALL, UNION ALL, UNION ALL…
Join in a table sharing column names… Everything breaks. You gotta put the new prefixes in front of all the headers you called in now. In every select, in every where, etc… Which is weird because that kinda works like a variable and it’s fine…
“When you see this little piece of text, it means all this, got it?”
“Okay. Yep. Easy.”
“So why can’t you do that with expressions?”
SQL SCREAMS MANICALLY
“Okay, okay, okay!.. Jesus…”
And then you try put a MAX in a where and it won’t let you because you gotta pull all the maxes out in their own query, make a table, join them in, and use them like a filter…
I hate it. It has speed, when you can finally run the script, but everything up to that is so…ugh.
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.
SQL enjoyer?
Every time I use it I feels like I’m going back to the 90s. No variables, no functions; Oh but you can do a CTE or subquery…👍
UNION ALL, UNION ALL, UNION ALL… “There’s got to be a better way, surely…”
looks up better way
“Oh, what the fuck?!.. Nope, this will just be quicker…” UNION ALL, UNION ALL, UNION ALL…
Join in a table sharing column names… Everything breaks. You gotta put the new prefixes in front of all the headers you called in now. In every select, in every where, etc… Which is weird because that kinda works like a variable and it’s fine…
“When you see this little piece of text, it means all this, got it?”
“Okay. Yep. Easy.”
“So why can’t you do that with expressions?”
SQL SCREAMS MANICALLY
“Okay, okay, okay!.. Jesus…”
And then you try put a MAX in a where and it won’t let you because you gotta pull all the maxes out in their own query, make a table, join them in, and use them like a filter…
I hate it. It has speed, when you can finally run the script, but everything up to that is so…ugh.
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.