¿SQLite sería menos útil sin aceptar inserciones de valores no numéricos en columnas numéricas?

En SQLite, la siguiente instrucción sería exitosa y la cadena se insertaría / actualizaría en la SALARYcolumna que es de tipo INTEGER:

update employee set salary='TOO MUCH' where emp_id=1;

Tenga en cuenta que no se insertará / actualizará cero, sino la cadena "DEMASIADO" real , por lo que no se trata de la conversión de tipo automática.

Las preguntas frecuentes dicen:

Esta es una característica , no un error. SQLite utiliza la tipificación dinámica. No aplica restricciones de tipo de datos. Los datos de cualquier tipo pueden (generalmente) insertarse en cualquier columna. Puede colocar cadenas de longitud arbitrarias en columnas enteras, números de coma flotante en columnas booleanas o fechas en columnas de caracteres. El tipo de datos que asigna a una columna en el comando CREATE TABLE no restringe qué datos se pueden poner en esa columna. Cada columna puede contener una cadena de longitud arbitraria. (Hay una excepción: las columnas de tipo INTEGER PRIMARY KEY solo pueden contener un entero con signo de 64 bits. Se producirá un error si intenta colocar algo distinto de un entero en una columna INTEGER PRIMARY KEY).

Por lo tanto, este comportamiento es claramente intencional, sin embargo, me pregunto por qué SQLite tiene este comportamiento, ya que la mayoría de las otras bases de datos SQL que conozco se comportan de manera muy diferente, generarían un error o convertirían la cadena 0 al intentar insertar una cadena no numérica en Una columna numérica.

• ¿La biblioteca SQLite sería menos útil sin este comportamiento?

• ¿Está hecho así por diseño para mantener la biblioteca pequeña y rápida?

• ¿La biblioteca SQLite sería significativamente más lenta o más grande para generar errores al intentar insertar una cadena en una columna numérica?

No, la escritura dinámica requiere más espacio de almacenamiento y más tiempo de procesamiento, especialmente porque también agregan afinidad de tipo, lo que significa que tiene un tipo preferido que el programador puede ignorar. Es realmente una característica intencional con costos reales de compensación. Esos costos son efectivamente insignificantes para los casos de uso de los objetivos SQLite, pero todavía están allí.

La utilidad de tales características es difícil de ver porque no está acostumbrado a tenerla disponible para usted. La solución para su falta se siente más natural para usted ahora. Debido a su experiencia previa, está pensando en él como un campo INTEGER que nunca será otra cosa, pero SQLite lo ve más como un campo de cualquier tipo, pero probablemente contendrá principalmente enteros. Quizás es un código postal para una empresa que principalmente hace negocios en los Estados Unidos, pero que tiene un puñado de clientes canadienses. Permitir que el usuario especifique una afinidad entera ahorrará mucho espacio al convertirlo en una cadena en cada fila, pero aún así le brinda esa opción.