Rezervace - kontrola datumu

Lisoe:
Porovnáš zadané datumy s těmi, které jsou v databázi (kolize nastává, pokud je požadovaný začátek později než nějaký v DB a současně požadovaný konec dříve, než zadaný v DB u téhož řádku).

Problém je konkrétně kde? To není o zápisu, ale o velké logice, ale spíše o lenosti.

Tomášeek:
„kolize nastává, pokud je požadovaný začátek později než nějaký v DB a současně požadovaný konec dříve, než zadaný v DB u téhož řádku“

To je jen jedna z možností, i když vyloučí tuhle situaci, pořád může kolize nastat.
Dá se říci, že jsou čtyři druhy kolizí:


Čili, když budu říkat „rezervace“ těm už uloženým a „interval“ ten nově požadovaný, šla by kolize dohledat jako rezervace splňující:
• Začátek intervalu leží uvnitř rezervace,
• NEBO Konec intervalu leží uvnitř rezervace,
• (3. typ splní obě předchozí podmínky, takže ten máme vyřešený, )
• NEBO (začátek intervalu je dřív než začátek rezervace a současně konec intervalu je později než konec rezervace)

Takže když nově zadávaný začátek a konec bude NFR a NTO, byla by podmínka na kolizní rezervaci asi takhle:
(NFR >= date_from AND NFR < date_to) OR (NTO > date_from AND NTO <= date_to) OR (NFR <= date_from AND NTO >= date_to)

Kolize nastává, pokud je začátek vkládaného řádku před koncem uloženého řádku a zároveň pokud je konec vkládaného řádku za začátkem toho samého uloženého řádku.

Takto to není někdy na první pohled jasné, ale dá se k tomu dojít i tak, že při hledání kolizí nás nezajímají dříve uložené řádky, které končí před vkládaným intervalem nebo které začínají až po vkladaném intervalu. Všechno ostatní jsou kolize.

Tedy nezajímají nás

Negace otočí znaménka a logické operátory a vyjde ta jednoduchá podmínka popsaná v první větě.

Pokud by to byl PostgreSQL, jde použít (start1, end1) OVERLAPS (start2, end2)

Lisoe:
A nebylo by lepší hned zezačátku vůbec nedat možnost vybrat již rezervovaný termín či čas? Prostě z dostupných rezervací nabídnout již jen ty volné?

ZdenekPNJ:
Ne vždy to jde. Navíc ta logika je tam stejná. A ať se kontroluje dopredne, nebo zpetne je už jedno.

ZdenekPNJ:
Dalším problémem je paralelní zápis. Kontrolovat se to stejně musí i na konci. Protože i když uživateli zobrazíš jen volné termíny a o si nějaký vybere, tak nevíš, zda v době kdy si vybíral neudělal nějaký jiný uživatel rezervaci s kterou to koliduje.

ZdenekPNJ:
U datetime od - do je jen v jednom jediném dni přes 3 miliardy kombinací - z toho bych nechtěl vybírat, raději si budu datetime zadávat.

Kajman:
Tak ono to nemusí být tak horké. Např. obě hranice můžou být omezené na celé půlhodiny (HH:00, HH:30). Délka trvání např. 00:30 - 02:00 hod. Pak už těch kombinací je reálný počet a dají se průběžně disablovat dle aktuální situace. Ukládání tohoto jako datetime (včetně data) mi přijde celkem validní.

Vycházím z toho, jak to může fungovat u reálného projektu. U jiného to může fungovat jinak a může jít klidně o milisekundy, tam výběr na místě nebude.

Kajman:
jj, chápu, máš pravdu