Em 19 de janeiro de 2016 10:59, Guimarães Faria Corcete DUTRA, Leandro
<[email protected]> escreveu:
> 2016-01-18 19:57 GMT-02:00 Tiago José Adami <[email protected]>:
>>
>> Regras de validação de campo, por exemplo, você poderá (deverá) fazer no
>> banco para garantir a integridade dos dados. Mas também precisará ter algo
>> no front-end para diminuir o tempo de resposta e distribuir mesmo que pouca
>> coisa o processamento.
>
> Isso é otimização precoce.  Geralmente não é o caso; geralmente, o
> tempo de resposta e a distribuição ficam melhores com as regras
> declaradas no banco; a segunda melhor situação é quando não dá para
> declarar tudo, e precisa também usar o famoso ‘código procedural’, mas
> ainda no banco.

Discordo. Vejo duas formas de validar campos no banco de dados (se
houverem mais alternativas, por gentileza elucidem-nas):
1) por restrições ou gatilhos que serão validados no momento de
inserir/alterar um registro;
2) por uma função no banco que pode ser chamada quando o usuário
transfere o foco de um campo para outro.

A primeira opção não prioriza a usabilidade. É semelhante àquelas
páginas WEB com zilhões de campos que só te indicam que você errou
quando você faz o envio (submit). Cada submit do usuário ocasionaria
um erro de banco que deveria ser tratado na aplicação. Se o usuário
errou na entrada de 5 campos, teria que dar 5 submits para corrigir
todos os campos, pois o banco de dados já pára na primeira constraint
que falhou e interrompe a transação. Isto aumenta o tráfego
desnecessariamente e aumenta o tempo para submeter o formulário.

A segunda opção causará maior tráfego de dados e CPU no servidor se a
cada evento de passar o foco para outro campo o campo anterior seja
validado através de uma função no banco. Imagine um usuário
pressionando TAB em um formulário sem parar...

Ambos os casos são ruins para clientes (aplicações cliente) que usam
conexões de baixa velocidade e/ou alta latência.


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a