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

9

In SQLite la seguente dichiarazione sarebbe andata a buon fine e la stringa verrebbe inserita / aggiornata nella colonna SALARY che è di tipo INTEGER :

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

Nota che lo zero non verrà inserito / aggiornato ma la stringa "TROPPO" attuale, quindi non si tratta della conversione del tipo automatico.

Le domande frequenti:

This is a feature, not a bug. SQLite uses dynamic typing. It does not enforce data type constraints. Data of any type can (usually) be inserted into any column. You can put arbitrary length strings into integer columns, floating point numbers in boolean columns, or dates in character columns. The datatype you assign to a column in the CREATE TABLE command does not restrict what data can be put into that column. Every column is able to hold an arbitrary length string. (There is one exception: Columns of type INTEGER PRIMARY KEY may only hold a 64-bit signed integer. An error will result if you try to put anything other than an integer into an INTEGER PRIMARY KEY column.)

Quindi questo comportamento è chiaramente intenzionale, tuttavia mi chiedo perché SQLite ha questo comportamento, dal momento che la maggior parte degli altri database SQL che conosco si comportano in modo abbastanza diverso, potrebbero generare un errore o convertire la stringa 0, quando provi ad inserire una stringa non numerica in una colonna numerica.

  • La libreria SQLite sarebbe meno utile senza questo comportamento?

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

  • La libreria SQLite sarebbe notevolmente più lenta o più grande per aumentare gli errori quando si tenta di inserire una stringa in una colonna numerica?

posta Tulains Córdova 06.04.2015 - 20:28
fonte

1 risposta

7

No, la digitazione dinamica richiede più spazio di archiviazione e più tempo di elaborazione, soprattutto perché aggiungono anche l'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. Questi costi sono effettivamente trascurabili per gli obiettivi SQLite dei casi d'uso, ma sono ancora lì.

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

    
risposta data 06.04.2015 - 21:00
fonte

Leggi altre domande sui tag