On 2018/06/29 10:23 PM, Thomas Kurz wrote:
b) I think that noone wants type affinity to be actually removed. I'd
just like an option to make SQLite behave like any other DBMS and
- respect the data type declared for a column
- reject column definitions with invalid types (e.g. "STRING")
Indeed, but that option does exist, it's called CHECK constraints (and
if you would like to get elaborate, even Triggers), but I also note
Bob's point that these do consume more resources (probably significantly
more in the case of Triggers) than had it been a Type-constraint. A
major advantage is that you can be the author of when to check and when
not to, you can be the author of what /exactly/ to check - DB Engines
vary in how they check[*], but with SQLite you are the master of your
destiny.
[*] - A good example is a VARCHAR(3) constraint. Adding the string
"MAMA" into that field will, depending on the DB:
- FAIL your query with an error in MSSQL, one that may never have popped
up during dev cycle but suddenly do in production.
- Truncate the string to "MAM" in MySQL, without an error at all, just
kill some data and move on!
- Put the string "MAMA" into the DB without an error in SQLite.
Which of these do you prefer? Whichever it is, you can mimic it in
SQLite with a trigger or check constraint. What you cannot do though, is
mimic SQLite's behaviour in any other Engine. Think about that.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
