Estava conversando com alguns colegas quando um ponto no mínimo polêmico foi levantado.
A questão da consistencia dos dados armazenados no Banco de Dados.
Seja Oracle, SQL Server, MySQL, etc… devemos validar e garantir os dados obtidos na aplicação ou através de constrains do BD e outros artefatos?
Os que possuem uma queda para DBA costumam dizer que o mais importante é que o BD tenha seu próprio mecânismo de consistencia… outros juram de pés juntos que devem ficar com a aplicação…
Proponho uma votação…
O que vc acha? Consistencia dos dados devem ser verificadas no BD ou na aplicação?
Na minha opinião é questão de bom senso. Se o banco de dados permite que você implemente a consistência sobre ele, então porque reinventar? Deixe este trabalho para os seus DBAs e vá pensar em coisas menos chatas do que persistência de dados .
No mínimo no BD, para garantir uma validação realmente segura dos dados (óbvio, desde que seja bem feita), mas consistir em aplicação permite que sua interface com o usuário seja melhor elaborada. Erros de DB constraints são chatos de recuperar e tratar.
Pelo menos no banco, mas sem entrar demais nos detalhes do banco escolhido, normalmente definir campos null/not null e usar chaves extrangeiras já é suficiênte. Ou seja, consistencia ao menos estrutural o banco deve garantir. O resto fica melhor sendo implementado na camada de negocios.
A grande vantagem de deixar a verificação de consistencia para o RDBMS é que hot backups podem ser feitos com menor degradação de performance que seria com validação 100% pela aplicação.
Nao gosto de concentrar muita validacao no BD, geralmente fico soh nas FK e NULL/NOT NULL (e campos que nao precisam de ordenacao eu taco como string (CHAR, VARCHAR, etc) mesmo).
MAS validacao no BD tem (pelo menos) um ponto positivo - se voce usa os dados em mais de uma aplicacao, a validacao fica concentrada, evitando inconsistencias. Claro, ambas poderiam (e na maioria das vezes irao) validar, mas a validacao bem-feitinha no BD evita eventuais incompatibilidades entre as aplicacoes.
Eu recentemente tenho mudado minha opiniao sobre validacao de dados no banco de dados, pelo menos em relacao de FK. Esse tipo de feature’s de banco de dados colocam um grande peso e a utilidade pratica, atualmente, nao eh muita.
Em geral, as proprias interfaces graficas tendem a fazer a validacao para voce, por exemplo: quando voce teoricamente precisa fazer uma FK entre duas tabelas, na pratica o que ocorre? Na interface do usuario voce vai apresentar a segunda tabela com um componente tipo lookup table, um combo box com as opcoes dessa segunda tabela. Ou seja, a validacao esta sendo feita implicitamente, simplesmente o usuario nao tem como escolher um dado nao valido.
Com o advento de tecnicas novas, entao, como por exemplo os CMP’s , ate o cascade delete , que seria uma das grandes utilidades das FK nao tem muito sentido, pois o cascade delete mode ser aplicado pelo proprio container EJB, sem necessidade de chaves em banco de dados.
Agora realmente se vai ter programadores ruins podendo fazer cacas nas tabelas, talvez seja melhor usar as validacoes de BD, mas acho que com as tecnologias atuais, o peso eh grande para poucos beneficios.
Eu acho que o BD tem que garantir consistencia estrutural, como o louds colocou.
Mas sou contra colocar business logic no bd. Por exemplo, “not null”. Toda vez que eu vejo um not null, eu fico pensando em como me poderia ser útil o resto do registro sem aquilo. Muitas vezes eu descubro que eu nao quero de verdade que aquele registro seja deletado se eu remover a FK.
ainda mais pq requisitos mudam, dados precisam ser migrados, etc.
E se vc tá usando o banco pra persistencia de objetos? Putz, aí é que eu deixo quase tudo pra aplicacao.
A maioria das FKs com cascade delete tem mais a ver com a “existencia” da chave original, e nao com a inexistencia. Se eu deleto um usuário do meu sistema, eu ainda posso querer saber o que ele fez quando trabalhava pra mim. Nao quero que TODAS as informacoes sejam perdidas.
Tem muitas abordagens, eu acredito. Mas ficar com a consistencia só na aplicacao, como acontecia no Caché (nao sei a quantas anda o Caché, gracas aos céus) só pode levar a inconsistencias. Eu já vi dois usuários com mesmo username e passwords diferentes serem considerados dois usuários. E foi doloroso.
Isso me lembra o fato que bancos relacionais podem ate te garantir alguma consistencia estrutural sem te amarrar em 1 único vendedor, porem segurança dos dados é algo quase 100% inesistente.
Por essas e outras que sou muito mais utilizar LDAP para guardar os dados doque RDBMS.
Acho que as consistencias de dados devem ficar em ambos os lados, pois creio que uma das coisas mais pesadas em uma aplicação é o acesso à bancos de dados.
Se você tiver a validação na aplicação você evita que o usuário tenha que aguardar a resposta do banco para dizer se os dados são válidos ou não, diminuindo o tempo de resposta e diminuindo o trafego na rede.
Se por algum motivo a validação da aplicação falhar ou se os dados forem inseridos manualmente, você impede que dados inconsistentes sejam gravados no banco.
Ih, no quesito usabilidade entao dá pra uma thread nova. tempo de resposta nao é tudo, frustracao é que é a chave.
Numa app web, entao, vc ainda tem a opcao de validar várias coisas antes do post. Pra evitar a frustracao do usuário, vc tem que checar as coisas o quanto antes, e ajudar na correcao dos erros (por exemplo, pintando e/ou dando o foco no campo que tem erro).
Louds, fala sério, encontrei alguém que gosta de LDAP. Tá, entre LDAP e BD, a briga é dura pra ver quem é mais pentelho.
C tem alguma dica de como tornar a vida de um usuário LDAP menos sofrida? E quanto a vendor lock-in, o LDAP da Netscape, pelo menos (que agora chama-se Sun ONE Directory Server, aliás), é completamente egocentrico, até os tipos dos objetos tem prefixos “ns”.
Cara, a Sun fez a infeliz opção de continuar utilizando o servidor original da Netscape em vez de jogar fora e fazer algo direito.
Eu uso OpenLDAP, ele ainda não possui suporte a algumas coisas legais como extensões p/ transações, mas no resto funciona muito bem.
Quem vende um servidor realmente punk é o Novell Directory Server, segue direito maioria das rfc’s e todas extensões proprietarias são maioria relacionadas a administração.
Quanto ao Sun One DS, você não é obrigado a utilizar o schema que vem com ele.
A única coisa ruim mesmo é tentar trabalhar com LDAP via JNDI, é chato pacas.
Em java eu recomendo utilizar um package da novell para usar ldap, é outra coisa trabalhar com ele doque direto com JNDI. Muito alem disso não posso oferecer muito conselho pq eu quase sempre usei ldap com c/c++.
.