none
Dúvida na criação de tabela no sql server RRS feed

Respostas

  • Amigo, formato DATETIME, seve para armazenar o seguinte formato.

    dd/MM/yyyy  hh:mm:ss:mmm

    SMALLDATETIME

    dd/MM/yyyy hh:mm:ss

    Espero teer ajudado.!

    • Marcado como Resposta Giovani Cr sexta-feira, 18 de outubro de 2013 19:21
    quarta-feira, 16 de outubro de 2013 17:51

Todas as Respostas

  • Olá Claudio,

    Geralmente é utilizado o tipo datetime do SQL para representar datas em formulários de cadastro/alteração. 

    Pode ser que alguém venha a recomendar que você utiliza o smalldatetime, mas existe um porem, o seu range suportado é de 1900 até 2079 sendo que o datetime é 1783 té 9999 em termos de ano.

    http://technet.microsoft.com/pt-br/library/ms182418.aspx

    Vitor Mendes | http://www.vitormendes.com.br/

    "Ajuda teu semelhante a levantar a sua carga, porém, não a carregá-la." (Pitágoras)

    terça-feira, 15 de outubro de 2013 20:37
  • Existem diferentes tipos de data para o SQL (alguns SQLs possuem mais, outros menos, a lista abaixo é para a versão 2012).

    DateTime: aceita datas de 1/1/1753 a 31/12/9999, com precisão de 3 casas para milisegundos (ou seja, a hora pode ser expressada até 23:59:59.997). Este tipo gasta 8 bytes (e sim, isto É importante)

    SmallDateTime: aceita datas de 1/1/1900 a 6/6/2079. Gasta apenas 4 bytes, porém só tem precisão de minutos (ou seja, 23:59:59 é arredondado para 23:59).

    Date: Aqui é permitido somente datas (muito útil para data de nascimento, por exemplo). Gasta 3 bytes e trunca completamente horários. Pode conter datas de 1/1/1 até 31/12/9999 (semelhante ao .net).

    Time: Complementar ao Date acima, aceita somente horas, com até 7 dígitos de precisão em milisegundos (ex.: 23:59:59:1234567) e gasta uma quantidade variável de bytes: de 1 a 2 casas em ms, 6 bytes, de 3 a 4, 7 bytes e de 5 a 7, 8 bytes.

    DateTime2: É uma combinação do Date e do Time acima, gastando o mesmo que o Time, dependendo da precisão.

    DatetimeOffset: É uma data com hora (de 1 a 7 de precisão em milisegundos), mas com possibilidade de se adicionar o UTC da hora (muito útil para quando teu sistema funciona com fusos variados). Gasta 8, 9 ou 10 bytes dependendo da precisão.

    Um erro MUITO comum é achar que DEVE usar um tipo ou outro (por exemplo, em C#, todo mundo usa int, mesmo que os valores sejam muito menores que o limite de um int).

    Em teoria, quanto menos bytes você gastar para um tipo, menos espaço em disco o banco ocupa e mais rápido é sua indexação (também, índices em um Date, por exemplo, podem ficar mais tempo na memória porque ocupam bem menos espaço que um DateTime2, por exemplo). Dados em cache na memória sempre é bom, mas quando a memória é requisitada por outro processo, o cache acaba sendo destruído e novas requisições tem que vir do disco.

    Então, a regra geral é: use o suficiente para sua regra de negócio. Isso vai te dar uma performance melhor em vários aspectos.


    [] Blog: http://www.kodel.com.br

    • Sugerido como Resposta J.C.Kodel quarta-feira, 16 de outubro de 2013 02:00
    quarta-feira, 16 de outubro de 2013 02:00
  • Desculpa não ter explicado, é que eu preciso de um para o horário e data pois serão registrados automaticamente no formulário... O usuário não o colocará...
    quarta-feira, 16 de outubro de 2013 17:39
  • Amigo, formato DATETIME, seve para armazenar o seguinte formato.

    dd/MM/yyyy  hh:mm:ss:mmm

    SMALLDATETIME

    dd/MM/yyyy hh:mm:ss

    Espero teer ajudado.!

    • Marcado como Resposta Giovani Cr sexta-feira, 18 de outubro de 2013 19:21
    quarta-feira, 16 de outubro de 2013 17:51
  • aah, ok então... muito obrigado
    quarta-feira, 16 de outubro de 2013 18:07
  • Só ver a tabela que te passei.

    É realmente necessário ter precisão de 0.001 segundos?

    Sua informação será relevante se o horário não contiver segundos?

    Caso não precise deste tipo de precisão, vá de SmallDateTime, senão, vá de DateTime. O restante dos tipos de dados ou comportam somente uma parte (Data ou Hora) ou tem uma precisão muito maior do que você realmente precisa (como 7 dígitos em milisegundos ou informações extras sobre fuso horário).

    Novamente, não há obrigação alguma em se utilizar um tipo ou outro, vale o que sua regra de negócio requer e, obviamente, verificar se o tipo desejado realmente existe na versão do SQL que esteja utilizando (ou que seu cliente final utilize).


    Blog: http://www.kodel.com.br

    Por favor, marque como Resposta se lhe ajudei ;-)

    quarta-feira, 16 de outubro de 2013 18:10