> I hope you don't do a lot of code review. Or much coding, for that matter.
With responses like yours, I feel the same back at you. I always find it hilarious how passionate people can get about SQL just because it's hard to discuss without a full working example.
You should re-read and try out what I said. The schema in the example is contrived to create the very issue they're whining about, but bad schemas are at the root of all bad queries.
>>> The relationship between Orders and Products is one-to-many, not many-to-many.
Let's deal with this one first. Suppose customer 12 orders 10 pounds of gravel and a potted cactus while customer 15 orders 30 pounds of gravel and a cherry sapling.
I claim that this illustrates that it's possible for one order to be associated with multiple products (customer 12 placed an order for two different things), at the same time that it's also possible for one product to be associated with multiple orders (customers 12 and 15 each ordered gravel).
But you appear to know better than me. Please explain to me why it wasn't possible for the same product to appear in several orders.
> I always find it hilarious how passionate people can get about SQL just because it's hard to discuss without a full working example.
I actually don't have much in the way of opinions on SQL. But I do have strong opinions about self-righteous stupidity. You have repeatedly made it plain that you don't understand what the words you're using mean. Take this claim of yours:
> why aren't these tables normalized better anyway? None of them should have columns for the PK of another table.
The tables are already fully normalized. It would be possible to render them differently, so that (for example) the Orders table didn't have a column for CustomerID and instead a separate table existed with records of the form (OrderID, CustomerID) -- but this would not affect the normalization of the tables. All this would do is cause you to perform extra queries whenever you had one piece of information and you wanted the related piece of information.
Or this one:
> Also, OrderDetails is not a bridge table because it has the quantity of Products.
Annotating the relationship it embodies won't make OrderDetails not a bridge table. It's a bridge table because it records the many-to-many relationship between Orders and Products. Here ( https://www.youtube.com/watch?v=uKd01Ouw_b8 ) is a university lecture in which one of these tables is explicitly identified as a "bridge table" at the same time that it records such supplemental information. (In that case, what's happening is that the "AssignmentGrades" table bridges between "Assignments" and "Enrollments" while recording the grade each student earned on each assignment. This is fundamentally identical to OrderDetails bridging between Orders and Products while recording the quantity of each product purchased in each order.)
With responses like yours, I feel the same back at you. I always find it hilarious how passionate people can get about SQL just because it's hard to discuss without a full working example.
You should re-read and try out what I said. The schema in the example is contrived to create the very issue they're whining about, but bad schemas are at the root of all bad queries.