2008/5/14 Alexsander Rosa <[EMAIL PROTECTED]>: > Essa é uma questão sempre polêmica ...
Nah, já foi muito bem discutida. É que muita coisa foi discutida em papel, e é um assunto no qual os fornecedores de SGBDs não têm muito interesse, porque expõe deficiências do padrão SQL. > 2008/5/7 Leandro DUTRA <[EMAIL PROTECTED]>: >> >> 2008/5/7 Evandro Ricardo Silvestre <[EMAIL PROTECTED]>: >> > >> > > Por exemplo, e se a pessoa for tanto cliente como fornecedor? >> > > >> > Ou ela é cliente ou é fornecedor. O que pode acontecer de um fornecedor >> > querer comprar algo da empresa, assim no momento de uma venda o >> > fornecedor assume o papel do cliente. Mas ele não deixa de ser >> > fornecedor (o que é a realidade). >> >> Não é 'a realidade', isso é como sua empresa modela a realidade. >> >> Você vai estar cheio de NULLs numa tabela muito mais gorda do que três >> tabelas separadas. Você sempre vai ter de ler um atributo para saber >> como interpretar o resto. A base não vai garantir as regras de >> negócio, engordando o aplicativo e garantindo a presença de >> inconsistências a médio prazo. > > O que é uma tabela "cheia de NULLs"? Ter 3 ou 4 colunas com 90% dos valores > NULL numa tabela com 30 colunas é estar "cheio de NULLs"? Por exemplo. > O que é melhor, > desperdiçar alguns bytes ou ter que fazer um monte de JOINs pra fazer > qualquer consulta simples? A questão não é o desperdício de bytes, mas (1) a confusão conceitual com conseqüentes inconsistências de dados que certamente seguir-se-ão e (2) as dificuldades e ineficiências de atualização num ambiente transacional, assim como de uso de cache num de pesquisas. > Nessa mesma linha, cabe outra pergunta: o que é > uma tabela "muito mais gorda"? Uma tabela confusa, misturada, com mais campos do que os necessários para consultas e transações específicas. > Um outro exemplo: o endereço. Se uma "pessoa" (de qualquer tipo) pode ter > mais de um endereço, seria o caso de criar uma tabela "endereço" separada > com um relacionamento 1:N de modo de uma pessoa possa ter mais de um > endereço. O problema é que em 99,5% dos casos (acabei de conferir aqui pois > tenho um sistema modelado assim) o cliente tem apenas um endereço > cadastrado. Será que todo o trabalho necessário para buscar o endereço > compensa? Não seria mais fácil ter campos de endereço na própria tabela > "pessoa" e usar a tabela "endereço" apenas para os endereços alternativos? É > uma pergunta que já me fizeram várias vezes. E uma pergunta boba, porque não leva em conta a inconsistência no modelo de acesso. Toda a aplicação nesse caso teria de ter toda uma lógica de caso geral e especial, em vez de uma única lógica no caso geral. >> Se for um sistema muito pequeno, dá para administrar. Mas sempre será >> muito mais dor de cabeça que o necessário, e mais lento também. > > O que é um sistema "muito pequeno"? Com até 100.000 registros na tabela > "pessoa"? Até mais, em termos de volume de dados. Mas o que me preocupa é que sistemas evoluem, principalmente no sentido da complexidade; e precisam ser mantidos, quando inconsistências de dados tornam-se fatais e irritantes. Leitura, gente, conceito... -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED] _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
