Technologies: VS.net 2008, C#, Winforms, SQL Server 2008
So, I kind of screwed up at work and I apparently just promised to provide a visual query builder to the client with only 1 week left in the project. (I’m new to dealing with clients)
Either way, I’m trying to figure out the logic behind doing SELECT statement joins. (The query builder only has to do SELECT queries)
it’s easy enough to get the DBs table and column lists, and how to create “WHERE”, “AND” and “OR” parts, but I’m not sure how I should think about writing joins.
I have to develop it, because using an outside app, or .dll would require getting approval which could take over a year (Not an Option)
Is there a hard and fast rule that’s says “When writing a select statement, you use the table that has the most results as your “FROM” table, etc..)
I noticed MS Access mostly does Left Joins, but I don’t understand why.
EDIT: I’m no longer required to create it by the end of this week as the project is being delayed to architectural issues, however, I will be asking this question again in the hopes to get an answer to the “Logic” behind join statements
The real ‘logic’ behind SQL joins gets into relational algebra (I think Wikipedia has a nice high level overview – http://en.wikipedia.org/wiki/Relational_algebra). It’s a big topic, entire classes/books are devoted to it.
But I’m still a little confused by your question. If you are writing a visual query builder – you shouldn’t care about the logic behind joins. You can assume the relational database you are using will correctly handle that logic and return you the results. The only time you’d need to implement the actual logic for joining is if you were writing your own database.
If you are writing your own visual query builder you really just need a way for the user to indicate what type of join they want and to build valid SQL from it. Most tools I’ve seen use Left Outer Joins (like you mention Access does) because, inevitably, clients/customers/users will have bad or missing data. When you do an inner join they say, ‘Your tool doesn’t work, I should have 250 rows but I only got 232’. When you do an outer join they say, ‘I have 250 rows but some of them are missing data….I’d better fix that’. Left join seems more natural for most people (at least, I’m guessing, in places where people read Left to Right).
If you want your query builder to support everything that is possible in SQL – you’ve got a huge, huge, huge project….and like others have said – you are screwed. But the application I worked on had that, and people didn’t like it. They wanted a super-easy, limited, way of building queries. That can be pretty easy. I think you’ve got a great shot at putting together something along those lines. The ‘easy’ query building tool I put together used eight pre-defined queries and allowed the user to provide criteria at runtime. They couldn’t add tables, they couldn’t change the join types, they couldn’t do unions or aggregates or anything else. But they use that more than the full-feature ‘advanced’ commercial tool we purchased.
I hope that helps a little. Good luck!