I work with queries that are a little bigger than average, and it's very difficult to keep track of it unless it's well laid out.Ĭonditionals, loops, etc, get formatted like they would in a procedural language. Finally you determine which fields to get (which columns, the select-clause). Then you filter down to which records (which rows, the where-clause). First you decide the source of data (which tables). This would also mirror the other statements: insert, update, and delete, which begin with the table names. To understand the select-clause, I always first have to jump down to the from-clause anyway. Tangentially, it would have been better if SQL had the select-clause after the from- and where-clauses: You can put the filters in the joins, and I have in the past, but putting them in the where-clause better reflects the picture in my head. This giant table is then filtered through the where-clause, like a funnel. The join conditions are just to line up the rows of the different tables with each other, to avoid a cartesian product, to form one big table. > Why not put all predicates up in the join-clauses, > others in the join-clauses? What's the thinking here? > Why place some predicates in the where-clause and They all join together into one big from. But the joins are part of the from-clause. It's often arbitrary which tables are joined and which one is from'd. Are table2 and table3 less important than table1?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |