Temat: Operacje na dacie

Mateusz Komarnicki:

Piotr Lewandowski:

Nikodem Kler:

Kuba Świegot:

Michał Czerwiński:
Najcześciej robie tak, ze przechowuje date jako unixowy znacznik czasu w sekundach. Późniejsze operacje proste jak i skomplikowane są b. łatwe ;)

ja tak samo ;]

zawsze trzymam tylko STAMP w bazie.

nigdy sformatowaną datę.

TIMESTAMP używa się do "bieżących" dat, uwarunkowanych jego zakresem, do szerszych zastosowań należy stosować DATETIME, który ma nieco ;) większy zakres..

http://dev.mysql.com/doc/refman/5.1/en/datetime.html

Domyslam sie, ze Jakub przechwouja date w sekundach i zapisuje ja np. w polu integer. Aczkolwiek moge sie mylic ;)

Aczkolwiek mozesz wyjasnic o co ci chodzi? Bo ja tez sadze, ze najlepiej, najoptymalniej i najprosciej zapisywiac date w bazie jako uniksowe sekundy (date('U') w polu typu int(11).

Z powyższych naj... to chyba tylko najprościej pozostaje a i z tym bym polemizował.

Temat: Operacje na dacie

Wojciech Sznapka:
Swoją drogą, ile razy zdażyło wam się przenosić dużą aplikację z jednego typu bazy na drugą ?

Zależy co znaczy 'duża' i na czym jej wielkość ma polegać. Trzeba by chyba dokonać zgrubnego podziału na aplikacje/systemy pudełkowe typu sklep internetowy, który klient kupuje i stawia tam gdzie taniej a systemami klasy enterprise, gdzie wyboru silnika bazodanowego dokonuje się raz i przyjmując całkiem inne kryteria.

Temat: Operacje na dacie

ja wrzucilbym do integera wartosc z funkcji time(); robie tak juz 3 lata i od kiedy poznalem ten sposób nie zamienie na nic innego. duzo łatwiej jest napisac "SELECT * FROM tabela WHERE time<".(time()-86400).";" niz stosowac jakies sformatowane odgórnie daty. wiadomo mozna to potem za pomoca strtotime przekonwertowac do sekund, ale jakos przyzwyczailem się do trzymania time() i operowania na nim. Wielu znajomych tez tak robi.

Temat: Operacje na dacie

Szymon Perski:
ja wrzucilbym do integera wartosc z funkcji time(); robie tak juz 3 lata i od kiedy poznalem ten sposób nie zamienie na nic innego. duzo łatwiej jest napisac "SELECT * FROM tabela WHERE time<".(time()-86400).";" niz stosowac jakies sformatowane odgórnie daty. wiadomo mozna to potem za pomoca strtotime przekonwertowac do sekund, ale jakos przyzwyczailem się do trzymania time() i operowania na nim. Wielu znajomych tez tak robi.

Ale nikt Tobie ani Twoim znajomym nie powie, że robicie dobrze.
I wybacz, moim zdaniem czytelniejsze i prostsze do zrozumienia jest zapisanie
SELECT * FROM tabela WHERE time < now() - interval 1 day...
Przynajmniej nie ma takiego bezsensownego mieszania PHP z SQLem...Marcin Laber edytował(a) ten post dnia 05.07.08 o godzinie 23:10

Temat: Operacje na dacie

Marcin Laber:

Szymon Perski:
ja wrzucilbym do integera wartosc z funkcji time(); robie tak juz 3 lata i od kiedy poznalem ten sposób nie zamienie na nic innego. duzo łatwiej jest napisac "SELECT * FROM tabela WHERE time<".(time()-86400).";" niz stosowac jakies sformatowane odgórnie daty. wiadomo mozna to potem za pomoca strtotime przekonwertowac do sekund, ale jakos przyzwyczailem się do trzymania time() i operowania na nim. Wielu znajomych tez tak robi.

Ale nikt Tobie ani Twoim znajomym nie powie, że robicie dobrze.
I wybacz, moim zdaniem czytelniejsze i prostsze do zrozumienia jest zapisanie
SELECT * FROM tabela WHERE time < now() - interval 1 day...
Przynajmniej nie ma takiego bezsensownego mieszania PHP z SQLem...Marcin Laber edytował(a) ten post dnia 05.07.08 o godzinie 23:10

tak i tak w wielu miejscach przytrafia sie mieszanie php z sqlem wiec w tym przypadku to jest chyba bez różnicy ;]

Temat: Operacje na dacie

Szymon Perski:

Marcin Laber:

Szymon Perski:
ja wrzucilbym do integera wartosc z funkcji time(); robie tak juz 3 lata i od kiedy poznalem ten sposób nie zamienie na nic innego. duzo łatwiej jest napisac "SELECT * FROM tabela WHERE time<".(time()-86400).";" niz stosowac jakies sformatowane odgórnie daty. wiadomo mozna to potem za pomoca strtotime przekonwertowac do sekund, ale jakos przyzwyczailem się do trzymania time() i operowania na nim. Wielu znajomych tez tak robi.

Ale nikt Tobie ani Twoim znajomym nie powie, że robicie dobrze.
I wybacz, moim zdaniem czytelniejsze i prostsze do zrozumienia jest zapisanie
SELECT * FROM tabela WHERE time < now() - interval 1 day...
Przynajmniej nie ma takiego bezsensownego mieszania PHP z SQLem...Marcin Laber edytował(a) ten post dnia 05.07.08 o godzinie 23:10

tak i tak w wielu miejscach przytrafia sie mieszanie php z sqlem wiec w tym przypadku to jest chyba bez różnicy ;]

Oj...
Z tym mieszaniem SQLa z PHP to chyba nie masz racji. Większość osób, których doświadczenie cenię (ja zresztą też) przenosi coraz bardziej 'logikę' bazodanową jak najniżej. W samej aplikacji nie ma już praktycznie w ogóle SQL - wszystko dzieje się na poziomie frameworka, czy nawet ORMa.
I to nie dlatego, że tak jest szybciej czy bardziej optymalnie, tylko jest to łatwiejsze w zrozumieniu i utrzymaniu. Bo nie martwisz się przy pisaniu logiki o zgodność ze wszystkim w okolicy, a tylko z PHP. Zgodność z bazą osiągasz na poziomie frameworka/ORMa.

Temat: Operacje na dacie

Do tego logika na poziomie bazy pozwala zachować integralność nawet przy bezpośredniej interwencji.
Nie wiem czy Wam się zdarzało, ale mi tak, że z bazy nie korzystała tylko aplikacja w PHP, ale np. Java, i wtedy musiał byś pisać wszystko w obu, do tego zachowanie spójności było by kłopotliwe.
A z przenoszeniem bazy na inny silnik bazodanowy jest zawsze kłopotliwe, ale jak się wie co i jak nie stanowi to problemu.
(ja przenosiłem i z PG na MSSQL, z PG na MySQL, z MySQL na PG, najgorzej jak się przesiada z większej możliwości do mniejszych, bo wtedy logika trafia do aplikacji...)

Temat: Operacje na dacie

Tu sie zgodze, ale na pierwszy rzut oka tak samo. Nie mialem jeszcze okazji niczego przenosic. Nadmieniam takze ze nie negowalem rozwiazania pozostawienia logiki bazodanowej na poziomie zapytania.