Ik zou waarschijnlijk gaan voor een datumbereik kolom.
Dat geeft je de flexibiliteit om chunks van verschillende grootte te hebben en stelt je in staat om een uitsluitingsbeperking om overlappende bereiken te voorkomen.
Het vinden van de rij voor een bepaalde week is nog steeds vrij eenvoudig met behulp van de "bevat" operator @> , bijv. where the_column @> to_date('2019-24', 'iyyy-iw') vindt de rij(en) die weeknummer 24 bevatten in 2019.
De uitdrukking to_date('2019-24', 'iyyy-iw') geeft de eerste dag (maandag) van de opgegeven week terug.
Het is ook mogelijk om alle rijen te vinden die tussen de twee weken liggen, maar de constructie van de bijbehorende periode ziet er een beetje lelijk uit. U kunt ofwel een inclusief bereik maken met de eerste en de laatste dag:daterange(to_date('2019-24', 'iyyy-iw'), to_date('2019-24', 'iyyy-iw') + 6, '[]')
Of u kunt een bereik maken met een exclusief bovenbereik met de eerste dag van de volgende week:daterange(to_date('2019-24', 'iyyy-iw'), to_date('2019-25', 'iyyy-iw'), '[)')
Hoewel bereiken vrij efficiënt kunnen worden geïndexeerd en , zijn de vereiste GIST-indexen iets duurder om te onderhouden dan een B-Tree-index op twee integerkolommen.
Een ander nadeel van het gebruik van bereiken (als je de flexibiliteit niet echt nodig hebt) is dat ze meer ruimte innemen dan twee integerkolommen (14 byte in plaats van 8, of zelfs 4 met twee smallints). Dus als de grootte van de tabel van belang is, dan is uw huidige oplossing met de jaar/week-kolommen efficiënter.
Als je invoer een begin- en einddatum is om mee te beginnen (in plaats van een "weeknummer"), dan zou ik zeker gaan voor een daterange kolom. Als die begin- en einddatum meer dan een week beslaan, slaat u slechts één rij op in plaats van meerdere rijen.