First, your question is not with C#, it is in the SQL database query language, as you are using SQL Server, T-SQL. The commands you mount in C# are only actions to access the database, execute a query (or command/action) and then read the result.
Second, it would be good to study how to write querys independent of the application you are using, because the impact on the application is usually great, especially when the application goes into maintenance and has large data sets.
Mounting SQL in C# code without a treatment when you need to concatenate filters causes security problems, in which case you don’t, but it is important to take a look elsewhere. A reading on the subject (SQL Injection):
https://www.owasp.org/index.php/SQL_Injection
And third, there are other ways to perform Joins, depending on the data structure and how the information is stored, this knowledge promotes you a lot of flexibility when manipulating information, a reference taken from W3S:
Different SQL Joins Before we continue with examples, we will list the
types of the Different SQL Joins you can use:
INNER JOIN: Returns all Rows when there is at least one match in BOTH
Tables LEFT JOIN: Return all Rows from the left table, and the Matched
Rows from the right table RIGHT JOIN: Return all Rows from the right
table, and the Matched Rows from the left table FULL JOIN: Return all
Rows when there is a match in ONE of the Tables
And the link:
http://www.w3schools.com/sql/sql_join.asp
Edit by comments:
Only for those who don’t click in the link above, the first example of this link teaches how to make a Join that solves the problem. If you just want to copy the structure of a Join without knowing anything else, enter the link, copy and change the names of the columns and tables, if you want to learn what can be done with joins, read the link that is very basic.
In my experiences, when I had to work with large data sets, or even in routine performance analysis activities, I had to deal with the databases. Sometimes, avoiding a Join improves things, sometimes not making a select without a conditional improves things, but in all cases, I needed to know SQL and how it works to solve my problems, whether in a cluster or in isolated scope applications.
People make common mistakes just because they deliver the easy way, they think it’s the DBA’s fault because the data layer provides slow responses or they claim the server sucks, that’s the worst. But in the end, and with the amount of ORM tools being used now, the simple concepts of what not to do solve the case. So my advice is, Understand the flow of your application not to screw up.
A post on the website of Martin Fowler that I found interesting and that illustrates well the importance of working as a friend of DBA (I say in English):
http://martinfowler.com/articles/evodb.html#DbasCollaborateCloselyWithDevelopers
Even CI or CD require a database knowledge that goes beyond Joins. If you have worked on projects with more than 30 people, you know the difficulty of managing this kind of thing if your software process and the knowledge between bank and application is not balanced, the papers have to work together so you have no problems.
In short, I won’t copy a Join to make life easier now, when I can teach you other things that can improve your long-term life.
The post of @Luã Govinda Mendes Souza resolves more immediately, but, you should look for knowledge that brings a "more definitive solution".
You know how to use
joins
?– Jéf Bueno
No, I never had the need in my previous projects
– Hugo