Всъщност съм работил по проектирането и внедряването на система за хотелски резервации и мога да предложа следните съвети въз основа на моя опит.
Бих препоръчал втората ви опция за дизайн, съхраняваща един запис за всяка отделна комбинация от дата/хотел. Причината е, че въпреки че ще има периоди, в които цената на хотела е една и съща през няколко дни, това е по-вероятно че, в зависимост от наличността, тя ще се променя с течение на времето и ще стане различна (хотелите са склонни да увеличават цената на стаята, когато наличността пада).
Освен това има и други важни части от информация, които ще трябва да бъдат съхранени, които са специфични за даден ден:
- Ще трябва да управлявате наличността на хотела, т.е. на дата x имау налични стаи. Това почти сигурно ще варира в зависимост от деня.
- Някои хотели имат периоди на затъмнение, когато хотелът не е наличен за кратки периоди от време (обикновено специфични дни).
- Време за изпълнение – някои хотели позволяват резервиране на стаи само определен брой дни предварително, това може да се различава между дните от седмицата и почивните дни.
- Минимален брой нощувки, отново данни, съхранявани по индивидуална дата, която казва, че ако пристигнете в този ден, трябва да останете x брой нощувки (да речем през уикенда)
Също така помислете за човек, който резервира едноседмичен престой, заявката в базата данни за връщане на цените и наличността за всеки ден от този престой е много по-сбита, ако имате запис за цените за всяка дата. Можете просто да направите заявка, където датата на цената на стаята е МЕЖДУ датата на пристигане и заминаване, за да върнете набор от данни с един запис на дата на престоя.
Осъзнавам, че с този подход ще съхранявате повече записи, но с добре индексирани таблици производителността ще бъде добра и управлението на данните ще бъде много по-лесно. Съдейки по вашия коментар, вие говорите само в района от 18 000 записа, което е доста малък обем (системата, върху която работих, има няколко милиона и работи добре).
За да илюстрирате допълнителното управление на данни, ако НЕ съхранявайте по един запис на ден, представете си, че хотел има цена от 100 USD и 20 стаи на разположение за целия декември:
Ще започнете с един запис:
1-Dec to 31st Dec Rate 100 Availability 20
След това продавате една стая на 10 декември.
Вашата бизнес логика вече трябва да създаде три записа от горния:
1-Dec to 9th Dec Rate 100 Availability 20
10-Dec to 10th Dec Rate 100 Availability 19
11-Dec to 31st Dec Rate 100 Availability 20
След това курсът се променя на 3 и 25 декември на 110
Вашата бизнес логика вече трябва да раздели данните отново:
1-Dec to 2-Dec Rate 100 Availability 20
3-Dec to 3-Dec Rate 110 Availability 20
4-Dec to 9-Dec Rate 100 Availability 20
10-Dec to 10-Dec Rate 100 Availability 19
11-Dec to 24-Dec Rate 100 Availability 20
25-Dec to 25-Dec Rate 110 Availability 20
26-Dec to 31-Dec Rate 100 Availability 20
Това е повече бизнес логика и повече разходи, отколкото съхраняването на един запис на дата.
Мога да ви гарантирам, че докато приключите, вашата система ще се окаже с един ред на дата така или иначе, така че можете да я проектирате по този начин от самото начало и да се възползвате от по-лесното управление на данни и по-бързите заявки към базата данни.
