Projekt kalendarza - baza danych mySQL

Witam,

 

chciałbym doradzić się w sprawie prostego projektu polegającego na stworzeniu kalendarza, w którym oprócz dat będą wyświetlane odpowiednie wydarzenia, imieniny itp… Chodzi mi o sposób zaimplementowania bazy danych, tak aby całość była wygodna w obsłudze i wydajna (zapytania do bazy danych nie zajmowały zbyt wiele czasu).

 

Załóżmy, że będę przygotowywał jedynie kalendarz, który będzie wyświetlał imieniny, oraz inne wydarzenia (Eventy) - w tym celu potrzebne będą dwie tabele:

 

Imieniny | Eventy

id             |  id

opis         |  opis

data         |  data

 

I tutaj zastanawiam się nad jedną rzeczą, otóż często data imienin i data eventów będzie się pokrywała - w związku, z tym czy nie powinienem utworzyć nowej tabeli przechowującej daty ?

 

I kolejne pytanie jaki typ danych wybrać dla zmiennej przechowującej datę - dodam, że rok nie będzie miał znaczenia - tylko miesiąc i dzień, dlatego nie wiem czy zastosować typ DATE, a może rozbić to na dwie zmienne typu INT (dzien, miesiac) ? Bo jeżeli zastosuję DATE, to będzie on również przechowywał rok - miesiąc - dzień (o ile się nie mylę nie da się zapisać tylko dnia i miesiąca w typie DATE). Co będzie mniej kosztowne?

 

Całość realizowana w PHP/MySQL,

Dziękuję za porady

Zasadniczo skorzystałbym z daty przechowywanej w formacie DATE ze względu na wydarzenia - te raczej będą miały określony rok.

Do pobierania informacji możesz wykorzystać funkcję DATE_FORMAT aby przeformatować datę do formatu DD-MM, ex.

SELECT * FROM `daty` WHERE (`typ` = 'IMIENINY' AND DATE_FORMAT(`data`, '%d-%m') = '19-11') OR (`typ` = 'EVENT' AND `data` = '19-11-2014')

Tych danych nie będzie dużo więc tego typu rozwiązanie zda egzamin.

No tak, ale imieniny też będą miały pole na datę - a tych już będzie całkiem sporo - w dodatku o ile się nie mylę, może się zdarzyć, że ktoś obchodzi imieniny kilka razy w roku.

To z samej definicji działania bazy danych jest niemożliwe. If you want read fast, cache it. Tu masz np. bardzo fajny indekser używane przez duże marki jak IBM czy Oracle: http://lucene.apache.org/solr/

 

 

Analiza poziom 0. Opisz dostępne akcje w swoim systemie. Inaczej go zaprojektujesz, jeśli chcesz wyciągać wydarzenia w danym dniu, a inaczej jeśli chcesz wiedzieć, kto kiedy obchodzi imieniny, jeszcze inaczej, gdy chcesz wiedzieć oba.

Np. Jeżeli jedyną akcją jest wyswietlenie wydarzeń w danym dniu, to ja bym zastosował taki model

Jedna tabela EVENTS, dyskryminatorem TYP (0 - generyczny, 1 - imieniny), założył indeks na datę (bo po niej bedzie szukanie) oraz http://en.wikipedia.org/wiki/Bitmap_index na kolumnę dyskryminatora. Dzięki temu unikniesz dwóch query lub jakiś pokręconych joinów/warunków jak chcesz wydobyć zarówno Eventy typu 0 jak i 1, a jeśli chcesz tylko któryś, to z indeksem bitmapowym w zasadzie nie poczujesz różnicy, że te dane siedzą w tej samej tabeli.

PS

Wiedz, że jak zastanawiasz się nad takimi rzeczami, zamiast tym co napisałem, to podchodzisz do projektowania systemu od d*** strony