(Resolvido) Melhor em performance

[Eric Developer]

Olá Galera!

Faz tempo que tenho essa dúvida e hoje resolvi postar neste forum pra saber a opinião de vocês:

Em uma tabela eu tenho uma determinada tabela e eu preciso saber se um registro já foi processado pelo sistema, e para isso posso fazer:

- Um campo DataProcessamento que receberá a data que o registro foi processado pela aplicação. Para listar os registros não processados posso usar: Where DataProcessamento IS NULL

ou

- Um campo do tipo BIT (Processado) mantendo o campo DataProcessamento para ser usado em relatórios.,

A dúvida propriamente dita é: usando um campo BIT eu consigo uma performance maior ou não faz diferença?

Obs: a tabela pode ter milhares de registros

valeu!!

[fulvio]

Boa tarde Eric,

Em relação a sua dúvida: comparar um campo BIT sem dúvida é mais rápido do que comparar um campo DATA. Da mesma forma que comparar um campo DATA é mais rápido do que comparar um campo STRING. Se a coluna for chave ou índice, a performance fica ainda melhor.

Mas uma coisa importante: o que um processamento rápido para vc? Mesmo processando milhares de registros e o resultado for de milisegundos, para mim dará na mesma se utilizei um campo BIT ou DATA.

Outra questão: você terá que criar dois campos. Um para a Data de Processamento e outro para informar se foi ou não processado. Deverão ser realizados dois controles. Logicamente quando a Data de Processamento está preenchida, o processamento foi realizado.

Será que vale realmente a pena ter dois campos de controle, dois campos para manipular, mais espaço alocado, etc... para ganhar alguns milisegundos de processamento? :.)

Faça os testes no sql, simulando as duas execuções. Veja custo/benefício em relação ao tempo de resposta (Mapa de Execução).

Se eu fosse implementar, escolheria a 1ª opção (processamento muito rápido também, pois estaria pegando as datas NULAS).

[Eric Developer]

Fulvio,

valeu pela resposta cara, foi o que eu pensei também, principalmente na questão de ter que aumentar o controle da aplicação se tiver que colocar dois campos ao invés de um.

[fulvio]

Por nada Eric. Principalmente no ponto de vista de controle. Sempre terá que atualizar duas colunas. Se em uma implementação esquecer, o controle ficará furado.

Precisando estamos ai!! :.)