Se você não se importa com o suporte a fuso horário em seu aplicativo, usar strings para consultas básicas no MongoDB deve funcionar bem (mas se isso importa, você desejará uma
Date real modelo). No entanto, se mais tarde você quiser fazer cálculos de data ou usar o Aggregation Framework com seu campo de data, é necessário que o campo seja realmente uma
Date modelo:http://docs.mongodb.org/manual/reference/aggregation/ #operadores de data
Por exemplo, você pode usar o
$dayOfWeek função na Date campo digitado. Você provavelmente poderia fazer algumas coisas simples como agrupar por ano usando
$substr (doc
) no MongoDB, mas o código resultante não será tão claro (nem provavelmente terá um desempenho tão bom). Embora não seja uma grande diferença, recomendo armazená-los como
Date tipos, se possível, em geral. Vejo nos docs para o driver Perl contra o qual os desenvolvedores são avisados usando o
DateTime devido ao fato de ser muito lento, então talvez se você usar Perl regularmente, e o Aggregation Framework não for um grande problema, seria melhor armazená-los como números ou como strings e convertê-los conforme necessário em Perl. Se o espaço for um problema, remova os caracteres desnecessários (como o
- ):20130613 ->
4 bytes for length of string
8 bytes encoded as UTF-8
NULL character
Seriam 13 caracteres. Um valor DateTime em BSON Por outro lado, /MongoDB requer 8 bytes (como faria o Perl
$time função). (Recomendo fortemente que você faça alguns testes de desempenho para descobrir se o impacto no desempenho de usar uma
Date digite MongoDB com Perl afetará seus fluxos de trabalho típicos.) 
