Witam, jak najlepiej i efektywniej przechowywać datę i godzinę w bazie danych ? Czy powinien być to typ string dla tych wartości?
0
0
MSSQL ma odpowiednie typy danych do przechowywania dat / jednostek czasu. Czy ich używać, czy może jednak datę/godzinę przechowywać inaczej zależy od tego, po co te dane przechowujesz i jak często (i do czego) będziesz z nich korzystał.
0
Silniki baz danych z reguly maja dedykowane typy do trzymania w nich daty i godziny i nalezy z nich korzystac. W zaleznosci od tego jaki to jest silnik te typy moga byc rozne - co wiecej w jednym silniku moze byc kilka typow sluzacych do przechowywania daty i godziny (np. jeden uwzglednia strefe czasowa a inny nie). Z uwagi na to iz Twój post nie zawiera informacji o tym z jakiej bazy korzystasz ciezko Ci coś doradzić, ale np. MS SQL posiada taki typ jak DateTime.
Przechowywanie daty i godziny w kolumnie o typie string to moim zdaniem porazka. Po to sa dedykowane typy aby z nich korzystac a nie kombinowac.
0
Na jednym forum piszą tak na innym inaczej. Tyle ile for tyle opinii :D Chodzi mi o MSSQL(tag). W mojej aplikacji używam ich do zapisu, odczytu i porównywania. Stworzyłem sobie kalendarz rezerwacji, który w zależności od wartosci w bazie danych generuje mi wolne terminy. Na swój sposób utworzyłem sobie: ** DataTime** data no i string godzina, no i zastanawiam się czy będzie to efektywne przy wielu rekordach?
Pozdrawiam
0
No to w takim razie zajrzyj do linka, który podał @somekind , to na pewno będzie wydajniejsze niż Twoje rozwiązanie :)
0
Osobiście ja w 99% zapisuję jako timestmap czyli w postaci inta, jakoś łatwiej mi dzięki temu formatować wyświetlaną datę czy dostosowywać do lokalnej godziny.
1
mr_jaro napisał(a):
Osobiście ja w 99% zapisuję jako timestmap czyli w postaci inta, jakoś łatwiej mi dzięki temu formatować wyświetlaną datę czy dostosowywać do lokalnej godziny.
Ale co w tym łatwego? Zarówno SQL Server ma funkcje do operowania i formatowania daty, jak i języki programowania mają typy datoczasowe. Używanie surowej liczby to raczej utrudnianie sobie życia niż ułatwianie.
0
Mi wygodniej, tym bardziej, że we własnym frameworku mam napisane funkcje gdzie operuję za pomocą tego np na czasie dla wybranej strefy czasowej, czy chociażby do obliczania czasu od lub do wydarzenia. Według mnie jak kto woli. Jak kiedyś w jednym projekcie byłem zmuszony do pracy na dacie w zwykłej postaci to moja wydajność spadła o połowę w tych miejscach ;)
0
@mr_jaro ale Ty na pewno piszesz o MS SQL?
Ciekawe, bo w MS SQL Timestamp nie ma nic wspólnego z datą i czasem.
Więcej - nie ma możliwości rzutowania Timestamp na DateTime.
Sam zobacz:
http://technet.microsoft.com/en-us/library/aa260631%28v=sql.80%29.aspx
To może pokaż jak to robisz, ciekawym strasznie... Albo się pomyliłeś (pewnie z MySQL), albo straszne głupoty wypisujesz.
1
Rejencina napisał(a):
Na jednym forum piszą tak na innym inaczej. Tyle ile for tyle opinii :D
Drutem związane a nie efektywne...
A tam gdzie piszą Ci, że datę przechowuj jako varchar (na przykład) to każ im się większym kamieniem w głowę puknąć.
Tak na marginesie, takie prawo internetu - każdy idiota może wypisywać totalne głupoty i twierdzić, że to prawda objawiona.
Musisz sobie dystans do tego wyrobić...
Chodzi mi o MSSQL(tag). W mojej aplikacji używam ich do zapisu, odczytu i porównywania. Stworzyłem sobie kalendarz rezerwacji, który w zależności od wartosci w bazie danych generuje mi wolne terminy. Na swój sposób utworzyłem sobie: ** DataTime** data no i string godzina, no i zastanawiam się czy będzie to efektywne przy wielu rekordach?
Pozdrawiam
Nie będzie efektywniejsze i nie jest to potrzebne do niczego, moim zdaniem.
Porównaj sobie ile bajtów zajmuje datetime w MSSQL i np. varchar czy char.
Ile potrzebujesz znaków na datę i godzinę w formacie yyyy-mm-dd hh:mm:ss?
20, a więc char(20) -> 20 bajtów a varchar(20) -> 22 bajty.
DateTime - 8 bajtów.
Jest różnica?
Już nie wspomnę o łatwości operowania na takich danych za pomocą wbudowanych funkcji:
http://msdn.microsoft.com/en-us/library/ms186724.aspx