Uma observação: não sou contrário à normalização (muito pelo contrário). Só estou instigando a discussão. =)
Vinicius 2008/9/18 Henrique de Castro <[EMAIL PROTECTED]> > Concordo com o Pedro e também sou a favor de bancos de dados normalizados. > Odeio duplicidade de dados hehe.. > > E tipo, quanto a desempenho, se vc fizer uma aplicação bem feita, preocupar > com índices, não fazer consultas excessivas, pode ficar tranquilo que o > desempenho está garantido :) > > > 2008/9/18 Pedro <[EMAIL PROTECTED]> > >> Lógico que tem vantagem, mas alguém se deparou com a situação: Fazer >> relatórios em um banco não normalizado? >> Não há consistência nos dados. >> >> =D >> >> Att, >> >> Vinicius Cruz escreveu: >> >> Aumenta a organização, diminui a duplicidade. >> >> Por outro lado, há uma possibilidade de aumento de performance, que é (a >> meu ver) o que o cliente mais quer. (Ele pouco se lixa pros nossos >> problemas). >> >> Vinicius >> >> 2008/9/18 Pedro <[EMAIL PROTECTED]> >> >>> O símbolo '=' é um 'join' implícito, portanto 'inner' e '=' são apenas >>> duas maneiras diferentes de representar uma mesma instrução, dentro de cada >>> banco de dados existe um módulo chamado processador de consultas, que >>> converte instruções SQL para uma nível mais baixo, assim uma mesma consulta >>> pode ser escrita de várias formas diferentes. >>> >>> Eu sou a favor de manter o banco mais normalizado possível, as consultas >>> se tornam mais complexas, mas aumenta a organização e diminui a duplicidade >>> de dados, entre outras vantagens. >>> >>> Att, >>> >>> Vinicius Cruz escreveu: >>> >>> Pra não perder o foco do email anterior... =) >>> >>> Sobre o que o Eric falou, "A idéia é manter a modelagem do seu banco da >>> forma que evite ao máximo a necessidade de se fazer um JOIN.", fiquei >>> pensando sobre o conceito de normalização no banco de dados, que, de certa >>> forma, "estimula"o JOIN, não? >>> >>> A 3º forma normal, por exemplo >>> >>> http://pt.wikipedia.org/wiki/Banco_de_dados_relacional#Terceira_Forma_Normal_.28FN3.29 >>> >>> Antes de usar o JOIN, eu constumava fazer algo assim: >>> SELECT * FROM tabela_1 t1, tabela_2 t2 WHERE t1.id=t2.id >>> >>> Essa forma é menos custosa que o join? >>> >>> Vinicius >>> ps.: tenho observado que constantemente tem um pos off-topic. Se estiver >>> incomodando algum participante da lista, é só falar... >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> Lista mailing [EMAIL >>> PROTECTED]://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br >>> >>> >>> -- >>> 'É um orgulho ter você como nosso cliente' >>> ____________________________ >>> Pedro Belmino >>> Desenvolvedor >>> >>> ArgoHost.net >>> Hospedagem Web com Facilidadehttp://www.argohost.net >>> Suporte Telefônico: (85) 3264 9944 / (11) 4063 4844 >>> Contato direto: Ramal 107 >>> E-mail: [EMAIL PROTECTED] >>> >>> >>> _______________________________________________ >>> Lista mailing list >>> [email protected] >>> http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br >>> >>> >> ------------------------------ >> >> _______________________________________________ >> Lista mailing [EMAIL >> PROTECTED]://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br >> >> >> -- >> 'É um orgulho ter você como nosso cliente' >> ____________________________ >> Pedro Belmino >> Desenvolvedor >> >> ArgoHost.net >> Hospedagem Web com Facilidadehttp://www.argohost.net >> Suporte Telefônico: (85) 3264 9944 / (11) 4063 4844 >> Contato direto: Ramal 107 >> E-mail: [EMAIL PROTECTED] >> >> >> _______________________________________________ >> Lista mailing list >> [email protected] >> http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br >> >> > > _______________________________________________ > Lista mailing list > [email protected] > http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br > >
_______________________________________________ Lista mailing list [email protected] http://codeigniter.com.br/mailman/listinfo/lista_codeigniter.com.br
