Prefer strict tables in SQLite
The article advocates for using STRICT tables in SQLite to avoid common datatype problems. By appending STRICT to a CREATE TABLE statement, SQLite enforces rigid typing similar to other SQL engines. This prevents inserting mismatched types, such as putting text into an INTEGER column, which would normally succeed in non-strict tables. For example, INSERT INTO people_strict (age) VALUES ('garbage') would error. However, values that can be losslessly converted, like the string '123' to integer, are still accepted. STRICT tables also reject bogus column types on creation; only INT, INTEGER, REAL, TEXT, BLOB, and ANY are allowed. Using a type like DATETIME or UUID would cause an error. For flexibility, the ANY datatype can be used, which accepts any value even in a strict table. A disadvantage is that existing non-strict tables cannot be altered to become strict; the workaround is to create a new strict table and copy data over, which risks errors if the original data has type mismatches.
STRICT tables prevent silent data corruption from type mismatches in SQLite.