[G.....n]

Jak powinno się przechowywać w bazie danych niepełną datę urodzenia? Wiem, że ktoś urodził się w 1865 i nie wiadomo kiedy dokładnie.
Albo wiadomo, że urodził się albo 8 kwietnia, albo 11 kwietnia, jak to zapisać?
#sql #bazydanych

[m.....l]

nie pomagajcie mu, tu zły człowiek.

[z.....a]

@marianbaczal: Nie słuchajcie Mariana, to tylko mały kotek.

[edgar_k]

Jak powinno się przechowywać w bazie danych niepełną datę urodzenia?

@Ginden: pytanie - po co.

[aaandrzeeey]

@Ginden: jaka baza danych?

[jARRodx]

@Ginden: Użyj hstore/jsonb i zapisuj rok, miesiąc i dzień w osobnych kluczach. Jeśli Twój usecase na to pozwala, to zastosuj daterange do zapisania możliwego zakresu dat.

[aaandrzeeey]

@ginden: zasadniczo:
dodaj 4 kolumny:
data date (może być null)
rok tinyint/int (może być null)
miesiąc tinyint/int (może być null)
dzień tinyint/int (może być null)

tam gdzie znasz datę zapisuj w polu data (i ew. na intach), tam gdzie nie znasz zapisuj na intach - te informacje które znasz, np rok i miesiąc.

przechowywanie niepełnej daty byłoby kompletnie bez sensu - lepiej przechowywać null - będzie to info dla filtrów, że

[G.....n]

@aaandrzeeey: Baza nie ma tu znaczenia.

[aaandrzeeey]

Baza nie ma tu znaczenia.

@Ginden: anyway, jak powyżej. a znaczenie ma techniczne...

[G.....n]

@jARRodx: No właśnie dla danych historycznych raczej nie ma date-range, tylko lista możliwych dat.
A czasem jest i range...

[G.....n]

pytanie - po co.

@edgar_k: Robisz stronę o monarchach europejskich w historii i chcesz dać możliwość wyszukiwania po dacie urodzenia.
Niestety, część królów ma nie w pełni znaną datę urodzenia, np. jedne źródła mówią o urodzeniu w czerwcu 1233, drugie o urodzeniu "pod koniec" 1232, a trzecie - o październiku 1233.

[jARRodx]

@Ginden: W takim przypadku źle do tego podchodzisz. To, co chcesz zapisać, nie jest datą. Nie znajdziesz dobrego rozwiązania, jeśli będziesz starał się to zapisać jako datę. Zwłaszcza, jeśli masz wiele opcji.
Zapisuj jako datę tylko to, co jest datą per se. Wszystko inne zapisuj w inny sposób. W przytoczonej sytuacji chyba najlepiej zrobić kolumnę uncertainbdate typu varchar obok standardowej bdate będącej typu date_. Będzie zabawa z wyszukiwaniem, wiem.

[G.....n]

@jARRodx: To jest data na poziomie logiki, tylko, że nie jest to typ "datetime".

[neib1]

tu zły człowiek.

@marianbaczal: Cauka znowu przez Ciebie przemawia Marian

[jARRodx]

@Ginden: "pod koniec 1232" to nie data. Pozostałe przytoczone przez Ciebie przykłady tak, ale "pod koniec" nie.
Pomyśl o tym tak - jeśli jest rozbieżność pomiędzy źródłami, to data nie jest znana, znane są pewne opinie na temat tego, jaka ona może być; w związku z tym tam, gdzie źródła podają datę, zapisuj datę a tam, gdzie źródła podają opinię, zapisuj opinię.

[plushy]

@Ginden: Daj timerange (lub nawet rok gdzieś wśrodku uznając że urodził się c. 1232) a resztę info jako tekst.

[G.....n]

@plushy: A jak szukanie?

[plushy]

@Ginden: Po zakresie dat, no chyba że to ma być wyszukiwarka na zasadzie "Kto się urodził w ten dzień co ja".

[d.....3]

@Ginden:
możesz datę trzymać w date dla indeksu, a osobno informację o dostępności danych rok/miesiąc/dzień w osobnych flagach, czy w jakimś small czy tiny int na bitach, tylko na potrzeby wyświetlania
na flagach możesz też trzymać informacje typu dokładnie/na poczatku/pod koniec/brak dla rok/miesiac/dzien
dla zakresu też możesz użyć flag poczatek zakresu/koniec zakresu
różne daty urodzenia trzymałbym oczywiście w osobnych rekordach
dla zakresów, to już zależy od wyszukiwania, albo osobny rekord albo