SQLite: Qual é a utilidade de especificar tipos de dados?

Além da resposta de Vérace:

Embora o SQLite não imponha classes de armazenamento como tipos de dados, você pode aplicar uma verificação de tipo mais rigorosa usando typeof()uma restrição, por exemplo

Some_Quantity real check (typeof(Some_Quantity) = 'real')

Você perde a coerção automática de tipo, por exemplo, impediria que os valores '1'fossem 1armazenados em uma coluna real (você teria que especificá-la como 1.0). No entanto, você pode permitir vários tipos:

Some_Quantity real check (typeof(Some_Quantity) in ('real', 'integer', 'null')

A flexibilidade de tipo do SQLite também é útil para permitir valores de indicadores “fora de banda” que de outra forma não seriam válidos para o tipo da coluna:

Year check (typeof(Year) = 'integer' or Year in ('illegible', 'not disclosed'))

A decisão duvidosa do SQLite de ignorar os tipos de coluna (eles chamam isso de "recurso"!) torna um pouco mais inútil especificá-los, mas ainda existem algumas razões para fazê-lo:

1. Documentação - pelo menos você sabe qual deve ser o tipo, mesmo que não seja aplicado.
2. Suporte a ferramentas - os tipos de coluna podem ser lidos programaticamente, e ferramentas (por exemplo, SQLiteStudio) podem ser mais úteis se souberem os tipos.
3. Interoperabilidade com outros bancos de dados - SQL não é realmente padrão e acho que a maioria das consultas só funciona em um banco de dados, mas se você vier a portar seu esquema para algum outro banco de dados, será muito menos trabalhoso se você tiver tipos especificados.

Se você não se importa com isso, não faz sentido. Você pode impor os tipos usando CHECKrestrições, mas isso é independente do tipo de coluna real, portanto, não é realmente relevante para esta pergunta.

Existem várias razões no SQLite para definir tipos de dados, ou como o SQLite os chama, "classes de armazenamento".

Se você ler esta página , ela fornecerá uma visão sobre a função e o raciocínio por trás dos tipos de dados SQLite. Em particular, as seguintes seções dessa página são interessantes.

No entanto, a tipagem dinâmica no SQLite permite que ele faça coisas que não são possíveis em bancos de dados tradicionais rigidamente tipados.

Ou seja, como a linguagem de programação C, o SQLite permite que você faça coisas muito estúpidas porque também permite que você faça coisas muito inteligentes - compare C com Java e SQLite com outros RDBMSs, por exemplo.

e:

Uma classe de armazenamento é mais geral que um tipo de dados.

Outra razão:

No SQLite, o tipo de dados de um valor está associado ao próprio valor, não ao seu contêiner. O sistema de tipos dinâmicos do SQLite é compatível com os sistemas de tipos estáticos mais comuns de outros mecanismos de banco de dados, no sentido de que as instruções SQL que funcionam em bancos de dados estaticamente tipados devem funcionar da mesma maneira no SQLite.

Também:

E assim, na maior parte, "classe de armazenamento" é indistinguível de "tipo de dados" e os dois termos podem ser usados ​​de forma intercambiável.

NB "na maioria das vezes ..."

Para maximizar a compatibilidade entre o SQLite e outros mecanismos de banco de dados, e para que o exemplo acima funcione no SQLite como em outros mecanismos de banco de dados SQL, o SQLite suporta o conceito de "afinidade de tipo" nas colunas. A afinidade de tipo de uma coluna é o tipo recomendado para dados armazenados nessa coluna. A ideia importante aqui é que o tipo é recomendado, não obrigatório.

Portanto, uma razão muito boa para essa generalidade é a compatibilidade com praticamente todos os mecanismos do mercado - e se o padrão não combina com você, você pode alterar o código (licença de domínio público). Outra razão pela qual o SQLite é o RDBMS mais popular do mundo!

Mais uma dica interessante:

Uma coluna com afinidade REAL se comporta como uma coluna com afinidade NUMERIC, exceto que força valores inteiros na representação de ponto flutuante. (Como uma otimização interna, pequenos valores de ponto flutuante sem componente fracionário e armazenados em colunas com afinidade REAL são gravados no disco como números inteiros para ocupar menos espaço e são automaticamente convertidos de volta em ponto flutuante à medida que o valor é lido. a otimização é completamente invisível no nível SQL e só pode ser detectada examinando os bits brutos do arquivo de banco de dados.)

Portanto, uma coluna com afinidade REAL (em oposição a INTEGER) realmente faz uma diferença funcional nos resultados de uma consulta e/ou cálculo. Por exemplo, a string '456.567' (o SQLite armazena BLOBs e números como binários como qualquer outro mecanismo de banco de dados SQL) seria tratado como 456.567 para cálculos NUMERIC, mas nenhuma tentativa seria feita para coagir '6&%$$$#3' em qualquer tipo de NUMERIC.

Uma suposição importante que o SQLite faz é que o programador é o rei e não o motor! Se, por algum motivo, você deseja converter '6&%$$$#3' para um INTEGER, então você pode criar seu próprio algoritmo para isso, mas o SQLite assume que se você deseja tratar '6&%$$$# 3' como INTEGER, então você deve ter uma boa razão para fazer essa escolha!

Uma maneira sucinta de colocar isso é que o SQLite oferece ferramentas muito poderosas, mas como qualquer ferramenta poderosa, é preciso ter cautela e moderação. Basicamente, o SQLite diz "você é um adulto - se você quiser dar um tiro na cabeça com a pistola de pregos que eu lhe dei, vá em frente, mas não me culpe se você se machucar!".

Além da página SQLite, esses links também são úteis ( 1 , 2 ).