Schema adattato
CREATE EXTENSION btree_gist;
CREATE TYPE timerange AS RANGE (subtype = time); -- create type once
-- Workers
CREATE TABLE worker(
worker_id serial PRIMARY KEY
, worker text NOT NULL
);
INSERT INTO worker(worker) VALUES ('JOHN'), ('MARY');
-- Holidays
CREATE TABLE pyha(pyha date PRIMARY KEY);
-- Reservations
CREATE TABLE reservat (
reservat_id serial PRIMARY KEY
, worker_id int NOT NULL REFERENCES worker ON UPDATE CASCADE
, day date NOT NULL CHECK (EXTRACT('isodow' FROM day) < 7)
, work_from time NOT NULL -- including lower bound
, work_to time NOT NULL -- excluding upper bound
, CHECK (work_from >= '10:00' AND work_to <= '21:00'
AND work_to - work_from BETWEEN interval '15 min' AND interval '4 h'
AND EXTRACT('minute' FROM work_from) IN (0, 15, 30, 45)
AND EXTRACT('minute' FROM work_from) IN (0, 15, 30, 45)
)
, EXCLUDE USING gist (worker_id WITH =, day WITH =
, timerange(work_from, work_to) WITH &&)
);
INSERT INTO reservat (worker_id, day, work_from, work_to) VALUES
(1, '2014-10-28', '10:00', '11:30') -- JOHN
, (2, '2014-10-28', '11:30', '13:00'); -- MARY
-- Trigger for volatile checks
CREATE OR REPLACE FUNCTION holiday_check()
RETURNS trigger AS
$func$
BEGIN
IF EXISTS (SELECT 1 FROM pyha WHERE pyha = NEW.day) THEN
RAISE EXCEPTION 'public holiday: %', NEW.day;
ELSIF NEW.day < now()::date OR NEW.day > now()::date + 31 THEN
RAISE EXCEPTION 'day out of range: %', NEW.day;
END IF;
RETURN NEW;
END
$func$ LANGUAGE plpgsql STABLE; -- can be "STABLE"
CREATE TRIGGER insupbef_holiday_check
BEFORE INSERT OR UPDATE ON reservat
FOR EACH ROW EXECUTE PROCEDURE holiday_check();
Punti principali
-
Non utilizzare
. Piuttostochar(n)
varchar(n)
, o meglio ancora,varchar
o solotext
. -
Non utilizzare il nome di un lavoratore come chiave primaria. Non è necessariamente unico e può cambiare. Usa invece una chiave primaria surrogata, meglio una
serial
. Effettua anche voci inreservat
più piccoli, indici più piccoli, query più veloci, ... -
Aggiornamento: Per uno spazio di archiviazione più economico (8 byte invece di 22) e una gestione più semplice, salvo inizio e fine come
time
ora e costruisci al volo un intervallo per il vincolo di esclusione:EXCLUDE USING gist (worker_id WITH =, day WITH = , timerange(work_from, work_to) WITH &&)
-
Poiché i tuoi intervalli non possono mai oltrepassare il confine della data per definizione, sarebbe più efficiente avere una
date
separata colonna (day
nella mia implementazione) e un intervallo di tempo . Il tipotimerange
non viene fornito nelle installazioni predefinite, ma viene creato facilmente. In questo modo puoi semplificare ampiamente i tuoi vincoli di controllo. -
Usa
EXTRACT('isodow', ...)
per semplificare escluse le domeniche -
Presumo tu voglia consentire il bordo superiore delle '21:00'.
-
Si presume che i bordi siano inclusi per il limite inferiore ed esclusi per il limite superiore.
-
Il controllo se i giorni nuovi/aggiornati si trovano entro un mese da "adesso" non è
IMMUTABLE
. Spostato daCHECK
vincolo al trigger, altrimenti potresti riscontrare problemi con il dump/ripristino! Dettagli:
A parte
Oltre a semplificare l'input e controllare i vincoli, mi aspettavo timerange
per risparmiare 8 byte di memoria rispetto a tsrange
dal time
occupa solo 4 byte. Ma risulta timerange
occupa 22 byte su disco (25 in RAM), proprio come tsrange
(o tstzrange
). Quindi potresti andare con tsrange
anche. Il principio della query e del vincolo di esclusione sono gli stessi.
Interrogazione
Avvolto in una funzione SQL per una comoda gestione dei parametri:
CREATE OR REPLACE FUNCTION f_next_free(_start timestamp, _duration interval)
RETURNS TABLE (worker_id int, worker text, day date
, start_time time, end_time time) AS
$func$
SELECT w.worker_id, w.worker
, d.d AS day
, t.t AS start_time
,(t.t + _duration) AS end_time
FROM (
SELECT _start::date + i AS d
FROM generate_series(0, 31) i
LEFT JOIN pyha p ON p.pyha = _start::date + i
WHERE p.pyha IS NULL -- eliminate holidays
) d
CROSS JOIN (
SELECT t::time
FROM generate_series (timestamp '2000-1-1 10:00'
, timestamp '2000-1-1 21:00' - _duration
, interval '15 min') t
) t -- times
CROSS JOIN worker w
WHERE d.d + t.t > _start -- rule out past timestamps
AND NOT EXISTS (
SELECT 1
FROM reservat r
WHERE r.worker_id = w.worker_id
AND r.day = d.d
AND timerange(r.work_from, r.work_to) && timerange(t.t, t.t + _duration)
)
ORDER BY d.d, t.t, w.worker, w.worker_id
LIMIT 30 -- could also be parameterized
$func$ LANGUAGE sql STABLE;
Chiama:
SELECT * FROM f_next_free('2014-10-28 12:00'::timestamp, '1.5 h'::interval);
SQL Fiddle su Postgres 9.3 ora.
Spiega
-
La funzione accetta un
_start
timestamp
come tempo minimo di inizio e_duration interval
. Fai attenzione a escludere solo tempi precedenti all'inizio giorno, non i giorni seguenti. Più semplice semplicemente aggiungendo giorno e ora:t + d > _start
.
Per prenotare una prenotazione che inizia "adesso", basta passarenow()::timestamp
:SELECT * FROM f_next_free(`now()::timestamp`, '1.5 h'::interval);
-
Sottoquery
d
genera giorni a partire dal valore di input_day
. Festività escluse. - I giorni sono incrociati con possibili intervalli di tempo generati nella sottoquery
t
. - Questo è incrociato con tutti i lavoratori disponibili
w
. - Elimina finalmente tutti i candidati che entrano in conflitto con le prenotazioni esistenti utilizzando un
NOT EXISTS
anti-semi-join, ed in particolare l'operatore di sovrapposizione&&
.
Correlati:
- Come si fa la matematica con gli appuntamenti che ignora l'anno? (per l'esempio di matematica delle date)
- Prevenire adiacenti / voci sovrapposte con EXCLUDE in PostgreSQL
- Calcola il lavoro ore tra 2 date in PostgreSQL