[firebase-br] Voltando ao assunto de segurança

[Joao Paulo Franqueto]

Me desculpe Magno, mas neste seu caso então seu código é "writeOnly" ou o
pessoal desta software house é muito fraco. Brincadeiras a parte, acredito
que no seu caso, o problema seja o pessoal da software house...

Sobre o código fonte em SP e Trigger acho que não deve ser grande ponto de
preocupação, pois em minha opinião a regra de negócio não deve ser
implementada em SPs e Triggers, pois impossibilita um teste automatizado de
qualidade, sem contar que o debug é mais difícil. Estes recursos devem ser
usados quando trazem grande ganho de performance ou quando são
processamentos simples que ajudam a manter um código fonte legível e
simples. Ainda com o FB, as SPs selecionáveis são um grande diferencial por
possibilitarem a criação de relatórios complexos com facilidade, mas como
isto não é regra de negócio, não tem com que se preocupar.

Muitos usam SPs para melhorar o desempenho do software, já que o mesmo foi
desenvolvido como client/server pois o acesso a uma SP é muito mais rápido
do que acessar várias tabelas e acabam colondo a regra de negócio nas SPs.
Mas neste caso, pode ser usado de maneira emergencial, mas a forma correta
ao meu ver, é usar desenvolvimento em camadas.

Sobre a proteção dos dados, é tão importante para o desenvolvedor quanto pro
cliente, pois ele deve estar sabendo do problemas que um acesso indevido
diretamente no banco de dados pode gerar, como um pagamento anulado
indevidamente, dados apagados, etc... estes item vão gerar preocupação e
fazer com que o cliente investa em segurança, colocando No-Break, sala
restrita, acesso controlado, rede e firewall bem configurado, etc...

Mas caso alguma outra empresa tente pegar o banco de dados para uma migração
de sistema, acho que o cliente tem o direito, pois os dados armazendos no
sistema desenvolvido são dele. Foi ele quem adicionou todos os dados
contidos lá.
Se está ocorrendo um caso destes, é ruim para quem desenvolveu aquele
software, mas o cliente deve ter seus motivos, como um sistema atual que não
lhe atende da forma que ele queria, ou um sistema que contêm vários bugs
etc...
Se o cliente estiver tomando a decisão errada, ele vai acabar voltando atrás
e neste momento você poderá cobrar tudo o que deixou de ganhar. Se ele não
voltar, é sinal que existe algo errado e você precisa melhorar...

Bom, acho que é isto...

João Paulo...


2008/8/14 Magno System <magno em speet.com.br>

> Eu tenho no meu site, demonstrativos (banco demonstrativo = banco de
> produção) com o código do banco todo aberto e olha que eu uso e abuso de
> triggers e stored procedures e honestamente não me incomodo nem um pouco,
> pois com certeza é muito mais difícil uma software house estudar o código
> do
> meu banco e fazer um programa em cima do que começar o projeto do zero.até
> porque muitas vezes uma STORED PROCEDURE é tratada no código fonte do
> programa (no meu caso DELPHI) para ela poder desempenhar seu papel.
>
> Para se ter idéia recentemente eu vendi um fonte (banco de dados + delphi)
> para uma software house e a mesma constantemente me procura fazendo com que
> 80% das alterações eu mesmo tenha que fazer.
>
> Quanto aos dados eu concordo. Mas aí um linux bem instalado resolve
> bloqueando o acesso físico ao banco.
>
>
>