O SQLite seria menos útil sem aceitar inserções de valores não numéricos em colunas numéricas?


10

No SQLite, a seguinte instrução seria bem-sucedida e a cadeia seria inserida / atualizada na SALARYcoluna do tipo INTEGER:

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

Observe que zero não será inserido / atualizado, mas a sequência "MUITO" real , portanto, não se trata de conversão de tipos automáticos.

O FAQ declara:

Este é um recurso , não um bug. SQLite usa digitação dinâmica. Não impõe restrições de tipo de dados. Dados de qualquer tipo podem (geralmente) ser inseridos em qualquer coluna. Você pode colocar seqüências de caracteres arbitrárias em colunas inteiras, números de ponto flutuante em colunas booleanas ou datas em colunas de caracteres. O tipo de dados que você atribui a uma coluna no comando CREATE TABLE não restringe os dados que podem ser colocados nessa coluna. Cada coluna é capaz de conter uma cadeia de comprimento arbitrária. (Há uma exceção: as colunas do tipo INTEGER PRIMARY KEY podem conter apenas um número inteiro assinado de 64 bits. Ocorrerá um erro se você tentar colocar algo diferente de um número inteiro em uma coluna INTEGER PRIMARY KEY.)

Portanto, esse comportamento é claramente intencional, no entanto, eu me pergunto por que o SQLite tem esse comportamento, já que a maioria dos outros bancos de dados SQL que eu conheço se comporta de maneira bastante diferente, eles gerariam um erro ou converteriam a cadeia 0, ao tentar inserir uma cadeia não numérica em uma coluna numérica.

  • A biblioteca SQLite seria menos útil sem esse comportamento?

  • Isso foi feito por design para manter a biblioteca pequena e rápida?

  • A biblioteca SQLite seria significativamente mais lenta ou maior para gerar erros ao tentar inserir uma string em uma coluna numérica?


9
Alguém disse uma vez que "um recurso é um bug, conforme descrito pelo departamento de marketing".
Dan Pichelman

3
Duvido que seja bom para desempenho e densidade de dados, embora possa ser benéfico para o tamanho do código. Em suma, eu chamaria isso de um recurso incorreto intencional (ou pelo menos adotado).
Deduplicator

3
"Parece-me uma limitação imposta a fim de permanecer uma biblioteca de pequeno porte e de baixo recursos normalmente utilizado para sistema embarcado que exigem desempenho em tempo real ..." Eu não posso imaginar uma verificação de tipo sendo nada mais do que uma gota no o intervalo de desempenho de tempo / espaço para operações que executam qualquer quantidade de E / S de disco. Além disso, eles precisam ter verificações adicionais no código, pois não podem simplesmente assumir que os dados terão um tamanho fixo; portanto, sem dúvida, a digitação dinâmica custa seu desempenho.
Doval

11
@ DocBrown Não porque eu digo isso, mas porque é sui generis .
Tulains Córdova

2
@ user61852 Sugiro que você reescreva a questão completamente e se concentre em saber se a digitação dinâmica do SQLite ofereceria benefícios de desempenho e omita qualquer menção à distinção entre recurso / bug ou a utilidade / inutilidade geral da digitação dinâmica no contexto X ou Y.
Doval

Respostas:


8

Não, a digitação dinâmica requer mais espaço de armazenamento e mais tempo de processamento, especialmente porque eles também adicionam afinidade de tipo, o que significa que ele possui um tipo preferido que o programador pode ignorar. É realmente um recurso intencional com custos reais de troca. Esses custos são efetivamente desprezíveis para os destinos de SQLite dos casos de uso, mas ainda estão lá.

É difícil perceber a utilidade desses recursos, porque você não está acostumado a disponibilizá-los. A solução alternativa para essa falta parece mais natural para você agora. Devido à sua experiência anterior, você está pensando nele como um campo INTEGER que nunca deve ser outra coisa, mas o SQLite o vê mais como um campo de qualquer tipo, mas provavelmente conterá números inteiros. Talvez seja um CEP para uma empresa que faz negócios principalmente nos EUA, mas tem um punhado de clientes canadenses. Permitir que o usuário especifique uma afinidade inteira economizará muito espaço, transformando-a em uma sequência em todas as linhas, mas ainda oferece essa opção.


3
Eu escrevi uma atualização para minha pergunta sobre o armazenamento bem-sucedido da string "MUITO" em uma coluna numérica. A conversão automática inseriria zero. Além disso, esta é a primeira implementação de banco de dados relacional que eu sei que permitiria isso. Trabalhei com MSSQLServer, Oracle, PostgreSQL, MySQL, MS Access, DBase, Foxbase, COBOL e Sybase SQL Anywhere.
Tulains Córdova

2
Eu não entendo o seu comentário. Nada na minha resposta tinha algo a ver com a conversão automática.
Karl Bielefeldt

11
O SQLite as considera classes de armazenamento em vez de tipos de dados. sqlite.org/datatype3.html
JeffO 06/04

11
Promovido por ser claramente escrito, mas você está ignorando os problemas que isso provoca na comprovação da precisão dos dados. Você não pode extrair alguns números inteiros do seu banco de dados e assumir que eles serão números inteiros. ( "Tipagem dinâmica" é descontroladamente em desacordo com o modelo relacional propriamente dito .)
Wildcard

11
Os custos de ignorar completamente a digitação são muito maiores do que um pouco de espaço de armazenamento e tempo do processador.
precisa saber é
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.