Prawdopodobnie wybrałbym zakres dat kolumna.
Daje to elastyczność w zakresie różnych rozmiarów porcji i pozwala zdefiniować ograniczenie wykluczenia aby zapobiec nakładaniu się zakresów.
Znalezienie wiersza dla danego tygodnia jest nadal dość proste przy użyciu operatora „zawiera” @> , np. where the_column @> to_date('2019-24', 'iyyy-iw') znajduje wiersze zawierające numer 24 w 2019 r.
Wyrażenie to_date('2019-24', 'iyyy-iw') zwraca pierwszy dzień (poniedziałek) określonego tygodnia.
Można również znaleźć wszystkie wiersze, które znajdują się między dwoma tygodniami, jednak konstrukcja odpowiedniego zakresu dat wygląda trochę brzydko. Możesz zbudować zakres obejmujący pierwszy i ostatni dzień:daterange(to_date('2019-24', 'iyyy-iw'), to_date('2019-24', 'iyyy-iw') + 6, '[]')
Możesz też utworzyć zakres z wyłącznym górnym zakresem dla pierwszego dnia następnego tygodnia:daterange(to_date('2019-24', 'iyyy-iw'), to_date('2019-25', 'iyyy-iw'), '[)')
Chociaż zakresy można indeksować dość wydajnie i , wymagane indeksy GIST są nieco droższe w utrzymaniu niż indeks B-drzewa na dwóch kolumnach liczb całkowitych.
Inną wadą korzystania z zakresów (jeśli tak naprawdę nie potrzebujesz elastyczności) jest to, że zajmują więcej miejsca niż dwie kolumny liczb całkowitych (14 bajtów zamiast 8, a nawet 4 z dwoma smallintami). Jeśli więc rozmiar tabeli ma znaczenie, Twoje obecne rozwiązanie z kolumnami rok/tydzień jest bardziej wydajne.
Jeśli twoje dane wejściowe to data początkowa i końcowa (a nie „numer tygodnia”), zdecydowanie wybrałbym daterange kolumna. Jeśli data rozpoczęcia i zakończenia obejmuje więcej niż jeden tydzień, przechowujesz tylko jeden wiersz, a nie wiele wierszy.
