Jak działają wartości DATETIME w SQLite?

Tworzę aplikacje na Androida i muszę zapisać datę / godzinę utworzenia rekordu. Dokumentacja SQLite mówi jednak, że „SQLite nie ma klasy pamięci przeznaczonej na przechowywanie dat i / lub godzin” i „może przechowywać daty i godziny jako wartości TEKST, REAL lub INTEGER”.

Czy istnieje techniczny powód, aby używać jednego typu zamiast innego? I czy pojedyncza kolumna może przechowywać daty w dowolnym z trzech formatów od wiersza do wiersza?

Później będę musiał porównać daty. Na przykład w moich aplikacjach pokażę wszystkie rekordy utworzone między datą A a datą B. Obawiam się, że brak prawdziwej kolumny DATETIME może utrudnić porównania.

SQlite nie ma określonego typu daty i godziny. Można użyć TEXT, REALlubINTEGER typy, w zależności odpowiada Twoim potrzebom.

Prosto z DOCS

SQLite nie ma klasy pamięci przeznaczonej do przechowywania dat i / lub godzin. Zamiast tego wbudowane funkcje daty i czasu w SQLite mogą przechowywać daty i godziny jako wartości TEXT, REAL lub INTEGER:

• TEKST jako ciągi ISO8601 („RRRR-MM-DD GG: MM: SS.SSS”).
• REAL jako liczba dni juliańskich, liczba dni od południa w Greenwich 24 listopada 4714 rpne według proleptycznego kalendarza gregoriańskiego.
• INTEGER jako czas uniksowy, liczba sekund od 1970-01-01 00:00:00 UTC.

Aplikacje mogą wybrać przechowywanie dat i godzin w dowolnym z tych formatów i swobodnie konwertować między formatami za pomocą wbudowanych funkcji daty i czasu.

Wbudowane funkcje daty i czasu SQLite można znaleźć tutaj .

SQLite nie ma klasy pamięci przeznaczonej do przechowywania dat i / lub godzin. Zamiast tego wbudowane funkcje daty i czasu w SQLite mogą przechowywać daty i godziny jako wartości TEXT, REAL lub INTEGER:

TEKST jako ciągi ISO8601 („RRRR-MM-DD GG: MM: SS.SSS”). REAL jako liczba dni juliańskich, liczba dni od południa w Greenwich 24 listopada 4714 rpne według proleptycznego kalendarza gregoriańskiego. INTEGER jako czas uniksowy, liczba sekund od 1970-01-01 00:00:00 UTC. Aplikacje mogą wybrać przechowywanie dat i godzin w dowolnym z tych formatów i swobodnie konwertować między formatami za pomocą wbudowanych funkcji daty i czasu.

Powiedziawszy to, użyłbym INTEGER i przechowałbym sekundy od epoki Uniksa (1970-01-01 00:00:00 UTC).

Jedną z potężnych funkcji SQLite jest możliwość wyboru typu przechowywania. Zalety / wady każdej z trzech różnych możliwości:

• Ciąg ISO8601

  • Porównanie ciągów daje prawidłowe wyniki
  • Przechowuje ułamki sekund, do trzech cyfr dziesiętnych
  • Potrzebuje więcej miejsca do przechowywania
  • Jego wartość zobaczysz bezpośrednio podczas korzystania z przeglądarki bazy danych
  • Potrzeba analizowania do innych celów
  • Modyfikator kolumny „default current_timestamp” będzie przechowywany w tym formacie

• Prawdziwy numer

  • Wysoka precyzja w zakresie ułamków sekund
  • Najdłuższy zakres czasu

• Liczba całkowita

  • Najniższa przestrzeń dyskowa
  • Szybkie operacje
  • Mały zakres czasu
  • Możliwy problem z roku 2038

Jeśli chcesz porównać różne typy lub wyeksportować do zewnętrznej aplikacji, możesz w razie potrzeby użyć własnych funkcji konwersji daty i godziny oprogramowania SQLite .

Praktycznie we wszystkich sprawach dotyczących daty i czasu wolę upraszczać rzeczy, bardzo, bardzo proste ... Aż do sekund zapisanych w liczbach całkowitych.

Liczby całkowite zawsze będą obsługiwane jako liczby całkowite w bazach danych, płaskich plikach itp. Wykonujesz trochę matematyki i przerzucasz ją na inny typ, a datę możesz sformatować tak, jak chcesz.

Robiąc to w ten sposób, nie musisz się martwić, gdy [wstaw tutaj bieżącą ulubioną bazę danych] zostanie zastąpione przez [przyszłą ulubioną bazę danych], która przypadkowo nie używała formatu daty, który wybrałeś dzisiaj.

To tylko trochę narzutów matematycznych (np. Metody - zajmuje dwie sekundy, w razie potrzeby opublikuję streszczenie) i upraszcza wiele operacji dotyczących daty / czasu później.

Przechowuj go w polu typu long. Zobacz Date.getTime()inew Date(long)