O que vocês acham da existência de um campo em uma tabela de um banco de dados do tipo int para armazenar a idade de um individuo, sendo que já existe um campo date para armazenar a data de nascimento???
Agradeço a atenção de todos…
O que vocês acham da existência de um campo em uma tabela de um banco de dados do tipo int para armazenar a idade de um individuo, sendo que já existe um campo date para armazenar a data de nascimento???
Agradeço a atenção de todos…
campo date para idade?!
seria no mínimo um campo int!
tendo a data de nascimento, acho irrelevante armazenar a idade
campo date não armazena int.
Isso mesmo, desculpa, o campo idade é do tipo int, me confundi… obrigado pela sua opnião…
…
pronto… corrigido!!!
Não e sim.
Não pois isso pode ser calculado em runtime facilmente. Basta adicionar um método getIdade() e dentro dele fazer o calculo.
Sim caso seu banco não ocupe espaço e a demanda de tráfego de dados não seja problema.
[quote=Hebert Coelho]Não e sim.
Não pois isso pode ser calculado em runtime facilmente. Basta adicionar um método getIdade() e dentro dele fazer o calculo.
Sim caso seu banco não ocupe espaço e a demanda de tráfego de dados não seja problema. [/quote]
Eu já tenho outra opnião…
por exemplo, eu me cadastro hoje com 27 anos, então obviamente daqui a 3 anos por exemplo terei 30 mas no cadastro vai continuar desatualizado.
se hover alguma rotina de atualização (que particularmente acho “perfumaria”) tudo bem em armazenar a idade
acho que seria mais interessante armazenar a data de nascimento e calcular a idade em tempo de execução
[quote=bruno.prestes]O que vocês acham da existência de um campo em uma tabela de um banco de dados do tipo int para armazenar a idade de um individuo, sendo que já existe um campo date para armazenar a data de nascimento???
Agradeço a atenção de todos…[/quote]
Obviamente que não. Mesmo se não existisse o campo de data de nascimento. Idade é uma função, não é um dado. Não faz sentido guardar uma função na tabela.
Fora que se vc colocar o campo idade, tem que criar um robot que fica atualizando esse campo todos os dias ( uma pessoa só faz anos uma vez por ano, mas pessoas fazem anos todos os dias).
Simplesmente isso é um modelo horrivel porque vai guardar não-informação e ainda por cima vai consumir mais recursos ainda usando o robot.
No máximo Idade seria uma função no banco ( se não estiver usando uma linguagem de programação fora do banco).
É desnecessário. Se com uma informação você consegue outra, não precisa das 2 no banco de dados. É como se fosse redundância de dados!
[quote=Marlon Meneses][quote=Hebert Coelho]Não e sim.
Não pois isso pode ser calculado em runtime facilmente. Basta adicionar um método getIdade() e dentro dele fazer o calculo.
Sim caso seu banco não ocupe espaço e a demanda de tráfego de dados não seja problema. [/quote]
Eu já tenho outra opnião…
por exemplo, eu me cadastro hoje com 27 anos, então obviamente daqui a 3 anos por exemplo terei 30 mas no cadastro vai continuar desatualizado.
se hover alguma rotina de atualização (que particularmente acho “perfumaria”) tudo bem em armazenar a idade
acho que seria mais interessante armazenar a data de nascimento e calcular a idade em tempo de execução[/quote]Concordo plenamente. [=
Nesse caso seria necessario criar uma trigger e aí vai. Apenas mostrei que existe a possibilidade e um motivo, apesar de que eu não adotaria essa prática. [=
Você faz ideia da quantidade de recursos gasta para se calcular a idade de uma pessoa? Esqueça acessoa banco, objetos em excesso na memória, leitura de arquivos, falta de memória, disco lento… A maior causa de lentidão em sistemas é cálculos em cima de datas.
Muito mais barato colocar um campo IDADE. Melhor ainda: contrata um programador pleno (estagiário não consegue) para ligar para as pessoas do cadastro e pergunta qual a idade nova dela. Rápido, barato, confiável e os usuários vão adorar a atenção dispensada a eles.
Nenhuma !
Criar um campo idade no banco é uma má prática de programação, já que ao fazer isso, você precisaria criar uma rotina para ficar atualizando os dados. Seria mais trabalhoso no momento do desenvolvimento e depois de implementado ficaria gastando os recursos do sistema desnecessariamente.
Mas ontem me surgiu uma dúvida semelhante: no sistema que estou desenvolvendo, preciso mostrar a data da última compra do cliente.
Neste caso, a decisão de criar a coluna “data da última compra” na tabela do cliente é mais difícil, uma vez que ao contrário do caso anterior, eu não precisaria criar um robô para ficar atualizando a data. O que eu faria, seria dar um update na coluna a cada vez que o cliente fizesse uma compra.
Mas ainda assim, preferi não criar a coluna “data da última compra” por questão de redundância de dados.
Se tenho uma tabela de “vendas” contendo as colunas “data” e “código do cliente”, já tenho uma forma de obter a informação desejada.
wellington_r, esse exemplo seu já entra em outro caso, pois não envolve banco de dados, ou seja, nesse caso seu ele já faz uma consulta no banco, dependendo das ocasioes (banco externo, muitos acessos, varios select do tipo apenas pra abrir uma consulta de uma venda), ai ja compensa ter um campo específico para isso
Por favor, não deixe o título do tópico INTEIRO EM LETRAS MAIÚSCULAS.
Tópico movido para o fórum de persistência.
Não compensa contratar uma pessoa para ficar ligando. O você investe em servidores que darão conta de fazer o serviço de cálculo sem problema.
[quote=josenaldo]Você faz ideia da quantidade de recursos gasta para se calcular a idade de uma pessoa? Esqueça acessoa banco, objetos em excesso na memória, leitura de arquivos, falta de memória, disco lento… A maior causa de lentidão em sistemas é cálculos em cima de datas.
Muito mais barato colocar um campo IDADE. Melhor ainda: contrata um programador pleno (estagiário não consegue) para ligar para as pessoas do cadastro e pergunta qual a idade nova dela. Rápido, barato, confiável e os usuários vão adorar a atenção dispensada a eles.[/quote]
e se o sistema servir apenas para mostrar a IDADE e servir para vários sistemas no mundo. que precisam acessar essa informação toda atualizada todo dia as 12:00h Horário de Brasília,
digamos que seja tanta gente que o sistema demore cerca de 5 minutos para processar tudo. (é um monte mesmo)
e 20 segundos para retornar os dados e 20 segundos para transferir os dados.
o requisito diz que não se pode salvar em arquivos no servidor. tudo tem que ser retornado do banco.
qual seria a melhor solução ? criar o campo IDADE e atualizar as idades as 11:50h OU fazer o calculo de 5 minutos por cada requisição?
sei que é extremamente incomum um sistema assim, mas pode existir
[quote=douglaskd][quote=josenaldo]Você faz ideia da quantidade de recursos gasta para se calcular a idade de uma pessoa? Esqueça acessoa banco, objetos em excesso na memória, leitura de arquivos, falta de memória, disco lento… A maior causa de lentidão em sistemas é cálculos em cima de datas.
Muito mais barato colocar um campo IDADE. Melhor ainda: contrata um programador pleno (estagiário não consegue) para ligar para as pessoas do cadastro e pergunta qual a idade nova dela. Rápido, barato, confiável e os usuários vão adorar a atenção dispensada a eles.[/quote]
e se o sistema servir apenas para mostrar a IDADE e servir para vários sistemas no mundo. que precisam acessar essa informação toda atualizada todo dia as 12:00h Horário de Brasília,
digamos que seja tanta gente que o sistema demore cerca de 5 minutos para processar tudo. (é um monte mesmo)
e 20 segundos para retornar os dados e 20 segundos para transferir os dados.
o requisito diz que não se pode salvar em arquivos no servidor. tudo tem que ser retornado do banco.
qual seria a melhor solução ? criar o campo IDADE e atualizar as idades as 11:50h OU fazer o calculo de 5 minutos por cada requisição?
sei que é extremamente incomum um sistema assim, mas pode existir[/quote]
Tá, admito… Você é bom… Tô até agora pensando se você está mesmo falando sério ou zoando que nem eu… srsrrssr Se isso foi trolagem sua, tenho que te dar os parabéns, foi muito boa (agora tô falando sério).
hahahaha, vou ser honesto, tive que me esforçar bastante pra pensar em alguma hipotese,
não sou DBA…
não foi trolagem, foi pra gerar debate mesmo…
Até que ponto um banco de dados deve ser normatizado ?
se a busca por desempenho é alta, a manutenção e integridade fica comprometida ?
quais seriam as melhores maneiras de aumentar o desempenho sem prejudicar a integridade, quais as melhores práticas, na verdade é isso que estou buscando…