Witam.

Zastanawiam się jak zapisac daty i godziny repertuaru kina. Mianowicie jak stworzyc tabele.

Tworze na poczatek id, id_film, id_kina, i tutaj mam teraz klopot bo nie wiem czy stworzyc dwa dodatkowe pola data, godzina
czy moze w wersji
data_od, data_do, godziny_seansow

W pierwszej tabeli bede mial duzo rekordow, ale wydaje mi sie ze ladniej i szybciej bedzie wyszukiwac repertuar danego kina i danego dnia ?!

Co o tym myslicie i jak wy byscie to rozwiazali ?

wystarczy jedno dodatkowe pole timetamp
ja po poltora roku archiwalny repertuar zaczalem przenosic do innej tabeli(ilestam mln rekordow), bo troche zaczelo zamulac (tzn. dzialalo szybko, ale ram żarło jak smok)

unix timestamp i w mysql masz pola typu int(11) lub po prostu pole typu DATE w mysql, zależy od tego, co Ci łatwiej obsłużyć po stornie php, ja osobiście korzystam z unix timestamp

tak btw. nie jestem purystą, ale w przypadku gdy chcesz wciskac godziny senasow w jedno pole to mocno zalatuje postacia "nienormalna" bazy

Dlaczego Timestamp a nie Datetime?

timestamp ma 4 bajty, datetime 8. timestamp lyka 1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07, a w tym przypadku nie ma watpliwosci ze taki zasieg wystarczy
timestamp jest wiec mniejszy i szybszy, nie jestem pewien czy datetime mozemy uzyc w foreign key

A jakie to ma przełożenie na wydajność czy na zużycie zasobów systemu? Czy piszemy soft na mikrokontroler dla pralki czy lodówki czy innego urządzenia o bardzo ograniczonych zasobach?

Co jest bardziej czytelne? '2010-01-10 01:01:01' czy 1263081661?

Czy zyski z 4 bajtów zamiast 8 bajtów będą w ogóle zauważalne, a jeżeli tak to czy wynagrodzą nam koszty związane z faktem, że przechowujemy dane w mniej czytelnej postaci w związku z tym:
- Programowanie będzie szło wolniej
- Łatwiej o błędy w kodzie wynikłe z nieprawidłowej interpretacji danych odczytywanych bezpośrednio z bazy.

Co gorsza timestamp jest uzależnione od strefy czasowej ustawionej na serwerze. Ewentualne błędy podczas konfiguracji serwera będą miały wpływ na nieprawidłowe działanie naszej aplikacji..

Wtrącę się i dodam, że timestampem łatwiej operuje się funkcją date(); a taki string 2010-01-01 00:00:00 zmienić do innej postaci to już kombinowanie. Dodanie do tego kilku godzin i wyświetlenie itp to też klocki.

To moje osobiste zdanie na ten temat. Jak dla mnie tylko i wyłącznie timestamp - bardzo rzadko inna forma.

wydawalo mi sie ze przelozenie na zuzycie zasobow systemu nie wymaga tutaj mechaniki kwantowej pamiec na indeks pola(a moze nie) i wartosci pola sa 8/4=2krotnie mniejsze. A tak bardziej serio to jak wspomnialem wyzej oraz jak wspomnial kolega ktory zadal pytanie, spodziewana ilosc rekordow moze przykroczyc 10^7 w przeciagu pol roku, wiec mysle ze jak mozna cos bezbolesnie zmniejszyc to dlaczego nie ?

inna sprawa, ze tak na dobra sprawe to to nie jest jakos specjalnie wazne czy wybierzesz stamp czy datetime, ale skoro juz mialem rzucic przykladem to wybralem ten bardziej odpowiedni moim zdaniem do takiej struktury, w sumie to mam naprawde w dupie ktorego bedziesz uzywal


jeszcze mniej czytelne byloby jakbys to w lolcode zapisal, ale o ile mi wiadomo kazdy klient(mowimy o MySQL), wlacznie z konsola, wyswietla date w formacie sformatowanym, wiec nie wiem o czym mowisz


jak wspomnialem 8/4 = 2 mysle ze jesli cos jest dwukrotnie mniejsze to mozna to zauwazyc


jak wspomnialem wyzej, moze mowimy o innym silniku bazodanowym, nie wiem co robi postgres i nie chce mi sie sprawdzac


ewentualne bledy w konfiguracji daty na serwerze zawsze beda mialy wplyw na aplikacje

Pewne minimum w znajomości biblioteki standardowej jest niestety konieczne. Sprawdź funkcję strtotime();





Fakt z brakiem czytelności może się zapędziłem. Ale datetime i tak sie tu broni. I nie piszę o postgres w mysql także bedzie to prawdą. Timestamp nadaje sie tam gdzie zapisujemy date zapisu rekordu w bazie. Datę jakiejs operacji w systemie. Jeżeli zapisujemy datę w rozumieniu logiki biznesowej wtedy datetime jest właściwy.


Nie pisalem o bledach w konfiguracji daty a o bledach w konfiguracji strefy czasowej. Przy data time nie beda one mial wplywu na aplikacje.

To fantastycznie, że chcesz mnie uczyć php ale czytaj ze zrozumieniem. "Zmienić do innej postaci" np do 01-01-2010 lub to co napisałem dalej. Nawet jeśli trzeba użyć tylko jednej ekstra funkcji to jest to kolejna, zbędna operacja ale jak piszę - zależy to od programisty i wygody.
Starasz się narzucić swoje zdanie mi i koledze yevaud ale gra trochę nie warta świeczki. Są to przyzwyczajenia programistów co każdy z nas podkreślił i dał swoje argumenty do używania tej funkcji więc nie na miejscu jest pisanie, że 'wtedy datetime jest właściwy'. Dla Ciebie może właściwe ale dla mnie mniej wygodne.

Nie funkcji tylko typu danych. Nie jest to kwestia wygody czy przyzwyczajenia. Każdy typ danych w bazie ma swoje przeznaczenie. Niestety swoje przyzwyczajenia musimy dostosowywać to rzeczywistości.

Strasznie się ~Smentek uwziąłeś na ten typ. ~Ramol użył poprawnego wyrazu: "funkcji". Czytaj ze zrozumieniem.

@yevaud Datatime i Timestamp to nie są funkcje.
Rozmawiamy o użyciu datatime vs timestamp dla pola przechowującego datę, które to pole reprezentuje czas seansu i to jest podmiotem naszej dyskusji prawda?

Zauważ jednak, że ~Ramol pisał o przerabianiu dat do innych postaci.