Choose case sensitivity deliberately for supplier codes
A supplier treats ab-12 and AB-12 as different identifiers, but a case-insensitive database collation considers them equal. A uniqueness failure or unexpected lookup may be a collation mismatch rather than a bad import.
Inspect the actual column collation
SHOW FULL COLUMNS FROM products LIKE 'supplier_code';
The database default, table default, and column collation can differ. Inspect the column used by the query and unique constraint. Do not assume a new environment inherited the same defaults as the original host.
Normalize only when the provider contract allows it
If codes are explicitly case-insensitive, normalizing them at the boundary can simplify storage and comparison. If they are case-sensitive, uppercasing destroys identity information. Keep the provider's documented semantics rather than choosing whichever form looks cleaner.
Changing a collation on existing data can reveal collisions or alter sort and equality behavior. Audit values before migration and plan how conflicting records will be resolved.
Test differently cased codes, accented text if relevant, and trailing-space behavior for the chosen type and collation. Verify both lookup and insertion under the unique index. An application-side strict string comparison cannot undo a database query that already matched the wrong row. Identity rules must remain consistent from incoming payload through persistence to outgoing API responses.