[Cascavel-pm] Bases de Dados[off-topic]

[Luis Motta Campos]

On Mar 27, 2007, at 3:18 AM, Nilson Santos Figueiredo Junior wrote:
> On 3/26/07, André Garcia Carneiro  
> <andre.garcia.carneir em terra.com.br> wrote:
>> Não consigo imaginar algo assim tão 'descartável', que realmente  
>> necessite de um SGBD. Para mim performance não
>> é desculpa para ter inconsistências nos dados. No final a lei de  
>> 'Murphy' sempre acaba ferrando a gente. :D
>
> Não é que seja algo completamente descartável. É algo que se *por
> acaso* for perdido, não trará tanto prejuízo assim.
>
> Só que o *por acaso* não significa que vai acontecer. Se o seu
> programa nunca deletar de uma tabela sem antes verificar se existem
> dados que referenciam a outra tabela, você nunca vai nem disparar a
> constraint de foreign key.

   Você nunca trabalhou com programadores trainees, trabalhou?
   Aqui na minha empresa não tem um trainee sequer. Mas tem uns caras  
que programaram Java a vida inteira e agora começaram a programar  
Perl... e, acredita, eles não tem cérebro. Merda é o sobrenome de  
algum deles, certamente. Eu não consigo saber por que ainda não tenho  
tanto holandês assim. Mas falta de cuidado e desleixo com a  
programação são comuns demais aqui.

   A empresa está tentando mudar isso, e a minha contratação – e a de  
mais duas pessoas com habilidades parecidas – é um movimento neste  
sentido. Claro, isso não vai ajudar nada se a gente não terminar de  
corrigir os problemas e não "cristianizar" os bárbaros que continuam  
por aqui...

   Eu tenho experiência que 90% dos programadores são vomitadores de  
código, pouco mais do que compiladores de especificações. Eles não  
usam o cérebro que têm para criticar a forma como as coisas são  
feitas, e nem se importam em construir a melhor solução possível,  
dentro dos parâmetros existentes.

> A idéia de constraints é ter uma camada a mais de segurança - o que é
> bastante útil. Mas não é imprescindível. Você pode ter um banco de
> dados perfeitamente coerente e coeso sem ter nenhum tipo de
> relacionamento definido no banco de dados, desde que sua aplicação se
> comporte corretamente.

   Claro. Desde que você possa supliciar os desenvolvedores que  
cometem erros com chibatadas, dama-de-ferro, e outros métodos de  
"descontração" semelhantes. ;-)

> Porém, bugs podem acontecer. Em vários casos, uma ou outra perda
> ocasional é algo crucial. Em outros casos não. Pense em um site como o
> orkut, por exemplo. Se uma pessoa perder um dos seus recados não vai
> ser o fim do mundo.

   Eu trabalho num sistema de faturamento.
   Todas as minhas tabelas, quer diretamente, quer com um ou – no  
máximo – dois níveis de indireção, representam dinheiro para a  
empresa, quer em faturáveis, quer em comissões e dividendos. O que  
você acha que a gente deveria fazer com um pretenso engenheiro de  
software que escolhe usar MySQL sem transações ou constraints FK para  
uma aplicação deste tipo?

> Bom, eu não tenho a menor idéia de como ele se comporta em uma tabela
> muito grande.

   Engraçado, eu não tenho tabelas pequenas em que testar isso... ;-)

> Claro que se por acaso já existirem relacionamentos não coerentes na
> sua tabela MyISAM, vai dar todo tipo de problema na sua tabela InnoDB
> se você simplesmente der um ALTER TABLE já que os dados serão copiados
> possivelmente sem verificação (acho que tem um SET FOREIGN_KEY_CHECK=0
> implícito). Por via das dúvidas, sempre tenha uma backup.

   Eu não vou me arriscar sem ter um programa esperto o bastante para  
conferir os relacionamentos da minha base de dados e determinar se eu  
tenho um conjunto de dados consistente ou não. Eu vou propor a  
migração, e vamos ver o que o pessoal aqui diz. Se eles determinarem  
que isso é interessante, vou ter eventualmente chance de construir um  
programa para conferir a consistência da minha base de dados.

   Mais sobre isso mais tarde, quando eu tiver isso encaminhado para  
o pessoal daqui.

   Obrigado todo mundo pelas considerações!
   Putamplexos!
--
Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
Perl fanatic evangelist, and amateur {cook, photographer}