Recognises a collation changing what a key means
The case and accent sensitivity of the columns in a key, which on most engines comes from a server or database default nobody chose here. Case-insensitive makes an IBAN and its lower-case form one key; case- and accent-sensitive makes Mägi and Magi two parties. Either can be right; an unexamined default cannot.
Can AI do this?
Not tested yet
No AI benchmark covers this knobit yet. New results are announced in the Can AI Do the Job? newsletter.
What it looks like in practice
Expected result: The collation and the case or accent sensitivity the key needs
How it is assessed: Flags the deficient case and passes the acceptable one. Deficient: SQL Server with the usual case-insensitive database collation: uk_dim_party_reference treats ee-00412 and EE-00412 as one party, and a migration from a case-sensitive source merges two customers into one with no error Acceptable: Identifiers normalised on load (IBAN upper-cased, spaces removed) so the key does not depend on collation, and the collation named in physical_options for the engines that accept it — making the key's meaning a decision in the model rather than a server setting
Also known as: Collation that changes what a key means (generated DDL)
Related knobits
Builds on
All 33 knobits of Generate and review DDL.
Source: Review checklist 08-ddl, row 19; UTS #10; ISO 9075