ESTRUTURA ADEQUADA
Pessoal, como estão todos?
Tenho uma duvida onde preciso gravar uma data na tabela só que por ser assim surgiu uma duvida.
Qual seria a maneira mais adequada para grava uma data na tabela?
Tipo:
Colocaria o campo como data realmente?
colocaria como string?
colocaria como numero longo?
Qual é mais pratico e qual é mais rapido em uma consulta?
Obrigado
Tenho uma duvida onde preciso gravar uma data na tabela só que por ser assim surgiu uma duvida.
Qual seria a maneira mais adequada para grava uma data na tabela?
Tipo:
Colocaria o campo como data realmente?
colocaria como string?
colocaria como numero longo?
Qual é mais pratico e qual é mais rapido em uma consulta?
Obrigado
O correto é gravar como campo data .
Até por isso que existe o tipo Date.
Até por isso que existe o tipo Date.
Bom realmente vou fazer minhas as palavras do colega ADHEL, as vezes um usuário leigo pode até não entender porque disso, porque tipos de campos diferentes, vou explicar para o caso do campo do tipo date.
quando vc salva uma data em um campo date você jamais tera pro0blemas com consultas entre duas datas o resultado será sempre o esperado.
porém algumas pessoas costumam salvar o campo como string, o que pode causar um problema na consulta, ai vc pergunta como? e eu digo:
suponha que um usuario salve datas em um campo string da seguinte maneira 21/01/2013, 01/03/2013 e 10/12/2013, quando ele for efetuar uma pesquisa entre 21/01/2013 e 10/12/2013 será retornado apenas o dia 21/01/2013.
agora vou explicar porque disso
vamos converter as data acimas para string, levando em consideração que as barras não existam, veja como o computador vai ler as datas
21012013
01032013
10122013
reparou, na realidade as datas viraram um sequencia numérica que ordenadamente ficariam assim
01032013
10122013
21012013
então é isso que causa o problema no caso de uma campo numerico será salvo de uma forma numérica diferente da data.
e é isso
quando vc salva uma data em um campo date você jamais tera pro0blemas com consultas entre duas datas o resultado será sempre o esperado.
porém algumas pessoas costumam salvar o campo como string, o que pode causar um problema na consulta, ai vc pergunta como? e eu digo:
suponha que um usuario salve datas em um campo string da seguinte maneira 21/01/2013, 01/03/2013 e 10/12/2013, quando ele for efetuar uma pesquisa entre 21/01/2013 e 10/12/2013 será retornado apenas o dia 21/01/2013.
agora vou explicar porque disso
vamos converter as data acimas para string, levando em consideração que as barras não existam, veja como o computador vai ler as datas
21012013
01032013
10122013
reparou, na realidade as datas viraram um sequencia numérica que ordenadamente ficariam assim
01032013
10122013
21012013
então é isso que causa o problema no caso de uma campo numerico será salvo de uma forma numérica diferente da data.
e é isso
Estou levando em conta o Access.
Pra trabalhar com o tipo numérico, vc precisaria salvar no formato americano ou a data totalmente invertida: yyyymmdd. A vantagem do número longo é que ele ocupa 4 bytes no mÃnimo e costuma ser um pouco mais rápido do que o tipo DateTime as buscas.
DateTime ocupa 5bytes, mas com ele vc pode fazer buscas por mês, ano, dia, semana, e qualquer outra função que trabalhe com Datas. E é mecanismo do banco de dados otimizado pra lidar com essas necessidades.
Texto vc não tem vantagem nenhuma: se vc gravar com dez caracteres, vc vai gastar 10 bytes no mÃninmo pra registrar a data. Pra consultar vc teria que fazer cast do tipo, ou seja, em tabela grandes, ia ser sofrÃvel.
Vai de Date e seja feliz!
Pra trabalhar com o tipo numérico, vc precisaria salvar no formato americano ou a data totalmente invertida: yyyymmdd. A vantagem do número longo é que ele ocupa 4 bytes no mÃnimo e costuma ser um pouco mais rápido do que o tipo DateTime as buscas.
DateTime ocupa 5bytes, mas com ele vc pode fazer buscas por mês, ano, dia, semana, e qualquer outra função que trabalhe com Datas. E é mecanismo do banco de dados otimizado pra lidar com essas necessidades.
Texto vc não tem vantagem nenhuma: se vc gravar com dez caracteres, vc vai gastar 10 bytes no mÃninmo pra registrar a data. Pra consultar vc teria que fazer cast do tipo, ou seja, em tabela grandes, ia ser sofrÃvel.
Vai de Date e seja feliz!
Obrigado a todos pelas respostas
A minha pergunta é meramente por estética de banco em caso de deixa-lo mais leve! onde eu trabalho eles abrangem uma estrutura conforme citado por nosso amigo LLAIA
eles adotaram por padrão salvar como numero yyyymmdd. Então essa seria a minha maior duvida será que é viavel apezar de criar códigos para conversão ou mantenho o meu padrão
que é salvar como um campo DateTime. Utilizo o banco SQL Server 2005. já no meu serviço é Oracle.
Resumindo, salvar como DateTime é mais viavél do que Numeric?
obrigado
A minha pergunta é meramente por estética de banco em caso de deixa-lo mais leve! onde eu trabalho eles abrangem uma estrutura conforme citado por nosso amigo LLAIA
eles adotaram por padrão salvar como numero yyyymmdd. Então essa seria a minha maior duvida será que é viavel apezar de criar códigos para conversão ou mantenho o meu padrão
que é salvar como um campo DateTime. Utilizo o banco SQL Server 2005. já no meu serviço é Oracle.
Resumindo, salvar como DateTime é mais viavél do que Numeric?
obrigado
sim principalmente se for pesquisar por mes, ano ou dia separadamente.
Ok, pessoal muito obrigado por esclarecer minha duvida
pensei que por questão de tamanho seria viavel ser tipo numerico, mas percebo que não em questões relatadas acima
Pois para que eu conseguisse fazer calculos eu teria que criar procedures e isso faria com que ficasse mais pesado
Mais uma vez Obrigado
pensei que por questão de tamanho seria viavel ser tipo numerico, mas percebo que não em questões relatadas acima
Pois para que eu conseguisse fazer calculos eu teria que criar procedures e isso faria com que ficasse mais pesado
Mais uma vez Obrigado
Tópico encerrado , respostas não são mais permitidas