Czy SQLite byłby mniej przydatny bez akceptowania wstawień wartości nienumerycznych do kolumn numerycznych?

W SQLite następująca instrukcja byłaby skuteczna, a łańcuch zostałby wstawiony / zaktualizowany w SALARYkolumnie typu INTEGER:

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

Zauważ, że zero nie zostanie wstawione / zaktualizowane, ale rzeczywisty ciąg „ZBYT DUŻO” , więc nie chodzi o automatyczną konwersję typu.

FAQ stanowi:

To funkcja , a nie błąd. SQLite używa dynamicznego pisania. Nie wymusza ograniczeń typu danych. Dane dowolnego typu można (zwykle) wstawić do dowolnej kolumny. Możesz umieszczać ciągi o dowolnej długości w kolumnach liczb całkowitych, liczb zmiennoprzecinkowych w kolumnach boolowskich lub dat w kolumnach znakowych. Typ danych przypisany do kolumny w poleceniu CREATE TABLE nie ogranicza danych, które można umieścić w tej kolumnie. Każda kolumna może przechowywać łańcuch o dowolnej długości. (Jest jeden wyjątek: kolumny typu INTEGER PRIMARY KEY mogą zawierać tylko 64-bitową liczbę całkowitą ze znakiem. Błąd pojawi się, jeśli spróbujesz umieścić coś innego niż liczba całkowita w kolumnie INTEGER PRIMARY KEY.)

Więc to zachowanie jest wyraźnie zamierzone, niemniej jednak zastanawiam się, dlaczego SQLite ma takie zachowanie, ponieważ większość innych baz danych SQL, które znam, zachowują się zupełnie inaczej, powodowałyby błąd lub konwersję ciągu 0 podczas próby wstawienia ciągu nienumerycznego do kolumna numeryczna.

• Czy biblioteka SQLite byłaby mniej przydatna bez tego zachowania?

• Czy jest to tak zaprojektowane, aby biblioteka była mała i szybka?

• Czy biblioteka SQLite byłaby znacznie wolniejsza lub większa w celu zwiększenia błędów podczas próby wstawienia ciągu do kolumny numerycznej?

Nie, dynamiczne pisanie wymaga zarówno więcej miejsca w pamięci, jak i dłuższego czasu przetwarzania, zwłaszcza, że ​​zwiększają one powinowactwo typów, co oznacza, że ​​ma preferowany typ, który programista może zignorować. Jest to naprawdę celowa funkcja przy rzeczywistych kosztach kompromisowych. Koszty te są praktycznie nieistotne w przypadkach użycia celów SQLite, ale nadal tam są.

Przydatność takich funkcji jest trudna do zauważenia, ponieważ nie jesteś przyzwyczajony do ich udostępniania. Obejście tego problemu wydaje się teraz dla ciebie bardziej naturalne. Z powodu twojego wcześniejszego doświadczenia myślisz o tym jako o polu INTEGER, które nigdy nie będzie niczym innym, ale SQLite postrzega to bardziej jako pole dowolnego typu, ale prawdopodobnie będzie zawierało liczby całkowite. Być może jest to kod pocztowy firmy, która głównie prowadzi działalność w Stanach Zjednoczonych, ale ma garstkę kanadyjskich klientów. Umożliwienie użytkownikowi określenia powinowactwa liczb całkowitych pozwoli zaoszczędzić dużo miejsca na tworzeniu ciągu w każdym wierszu, ale nadal daje tę opcję.