SQLite sarebbe meno utile senza accettare inserimenti di valori non numerici in colonne numeriche?

In SQLite la seguente istruzione avrebbe esito positivo e la stringa verrebbe inserita / aggiornata nella SALARYcolonna di tipo INTEGER:

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

Si noti che zero non verrà inserito / aggiornato ma la stringa "TOO MUCH" effettiva , quindi non si tratta della conversione del tipo automatico.

Le FAQ indicano:

Questa è una funzione , non un bug. SQLite utilizza la digitazione dinamica. Non impone vincoli di tipo di dati. I dati di qualsiasi tipo possono (di solito) essere inseriti in qualsiasi colonna. È possibile inserire stringhe di lunghezza arbitraria in colonne intere, numeri in virgola mobile in colonne booleane o date in colonne di caratteri. Il tipo di dati assegnato a una colonna nel comando CREATE TABLE non limita i dati che possono essere inseriti in quella colonna. Ogni colonna è in grado di contenere una stringa di lunghezza arbitraria. (C'è un'eccezione: le colonne di tipo INTEGER PRIMARY KEY possono contenere solo un numero intero con segno a 64 bit. Si verificherà un errore se si tenta di inserire qualcosa di diverso da un numero intero in una colonna INTEGER PRIMARY KEY.)

Quindi questo comportamento è chiaramente intenzionale, tuttavia mi chiedo perché SQLite abbia questo comportamento, poiché la maggior parte degli altri database SQL che conosco si comportano in modo abbastanza diverso, genererebbero un errore o convertiranno la stringa 0, quando provano a inserire una stringa non numerica in una colonna numerica.

• La libreria SQLite sarebbe meno utile senza questo comportamento?

• Questo è stato progettato in modo tale da mantenere la libreria piccola e veloce?

• La libreria SQLite sarebbe significativamente più lenta o più grande al fine di generare errori quando si tenta di inserire una stringa in una colonna numerica?

No, la digitazione dinamica richiede sia più spazio di archiviazione sia più tempo di elaborazione, soprattutto perché aggiungono anche affinità di tipo, il che significa che ha un tipo preferito che il programmatore è libero di ignorare. È veramente una caratteristica intenzionale con costi di scambio reali. Tali costi sono effettivamente trascurabili per i casi d'uso target SQLite, ma sono ancora lì.

L'utilità di tali funzionalità è difficile da vedere perché non sei abituato a averlo a tua disposizione. La soluzione alternativa per la sua mancanza ora ti sembra più naturale. A causa della tua precedente esperienza, lo stai pensando come un campo INTEGER che non dovrebbe mai essere nient'altro, ma SQLite lo vede più come un campo di qualsiasi tipo, ma probabilmente conterrà prevalentemente numeri interi. Forse si tratta di un codice postale per un'azienda che opera principalmente negli Stati Uniti, ma ha una manciata di clienti canadesi. Consentire all'utente di specificare un'affinità intera risparmierà molto spazio rispetto a renderlo una stringa in ogni riga, ma ti darà comunque quell'opzione.