Будет ли SQLite менее полезен, не принимая вставки нечисловых значений в числовые столбцы?

В SQLite следующий оператор будет успешным, и строка будет вставлена ​​/ обновлена ​​в SALARYстолбце, который имеет тип INTEGER:

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

Обратите внимание, что ноль не будет вставлен / обновлен, но будет содержать фактическую строку «СЛИШКОМ МНОГО» , так что речь идет не об автоматическом преобразовании типов.

В FAQ говорится:

Это особенность , а не ошибка. SQLite использует динамическую типизацию. Он не применяет ограничения типов данных. Данные любого типа могут (обычно) вставляться в любой столбец. Вы можете поместить строки произвольной длины в целочисленные столбцы, числа с плавающей запятой в логических столбцах или даты в символьных столбцах. Тип данных, который вы назначаете столбцу в команде CREATE TABLE, не ограничивает данные, которые могут быть помещены в этот столбец. Каждый столбец может содержать строку произвольной длины. (Существует одно исключение: столбцы типа INTEGER PRIMARY KEY могут содержать только 64-разрядное целое число со знаком. Ошибка будет возникать, если вы попытаетесь поместить в столбец INTEGER PRIMARY KEY что-то кроме целого.)

Так что это поведение явно преднамеренное, тем не менее, мне интересно, почему SQLite имеет такое поведение, так как большинство других баз данных SQL, о которых я знаю, ведут себя совершенно иначе, они вызовут ошибку или преобразуют строку 0 при попытке вставить нечисловую строку в числовой столбец.

• Будет ли библиотека SQLite менее полезной без такого поведения?

• Это сделано так, чтобы библиотека была маленькой и быстрой?

• Будет ли библиотека SQLite значительно медленнее или больше, чтобы возникли ошибки при попытке вставить строку в числовой столбец?

Нет, для динамической типизации требуется больше места для хранения и больше времени на обработку, тем более что они также добавляют сходство типов, а это означает, что у него есть предпочтительный тип, который программист может игнорировать. Это действительно намеренная функция с реальным компромиссом расходов. Эти затраты фактически незначительны для сценариев использования SQLite, но они все еще существуют.

Полезность таких функций трудно понять, потому что вы не привыкли иметь их в своем распоряжении. Обходной путь для его отсутствия теперь кажется вам более естественным. Исходя из вашего предыдущего опыта, вы рассматриваете его как поле INTEGER, которое никогда не должно быть ничем иным, но SQLite рассматривает его скорее как поле любого типа, но, вероятно, в основном будет содержать целые числа. Возможно, это почтовый индекс для компании, которая в основном ведет бизнес в США, но имеет несколько клиентов из Канады. Разрешение пользователю указывать целочисленное сходство сэкономит много места, превратив его в строку в каждой строке, но все же предоставит вам эту опцию.