June 27, 2019 at 6:45 pm
On top of that throw in that, the DDL and the DML have different rules. In DML, the {false, unknown} values are treated the same and reject a search condition. In the DDL, {true, unknown} values are treated the same and accept a check condition.
I look at it this way:
WHERE conditions must be TRUE in order to SELECT a row. This makes perfect sense. You wouldn't want to see rows that weren't known to meet the specific condition(s).
CHECK conditions must be known to violate the specified condition(s) in order to fail. This also makes sense. You wouldn't necessarily want to reject rows that you didn't know for sure required rejecting.
One could consider that inconsistent, but I don't think it's a bad set of rules.
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
June 27, 2019 at 7:54 pm
I voted for this convention when we added the CHECK() to the SQL Standards on the same grounds; "benefit of the doubt" principle 🙂
Please post DDL and follow ANSI/ISO standards when asking for help.
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply