Как правильно хранить таблицу с тарифами по часам?

Question

[petrun]

Все привет.
Может кто-нибудь сталкивался или есть идеи.
Есть тарифы - час аренды судна, тарифы бьются на дни недели, часы и могут быть различные категории пассажиров.
Судно не одно их будет много и у каждого будет своя тарифная сетка.
Нужно делать поиск по кораблям и выводить стоимость аренды за выбранный период.
Как лучше хранить и работать с данным?
Есть мысль сделать отдельную таблицу в которой будет по часам расписано на год вперед, но объем ее получается довольно большой (примерно 8760 строк на одно судно). Может есть более оптимальный способ?

Comments

[sim3x]

Сетку руками формируется или там есть закономерности?

[petrun]

Руками задается владельцем судна.

[sim3x]

petrun,

250 тыс строк на одно судно

руками?

[petrun]

sim3x, Нет конечно, это я прикинул если автоматически создавать таблицу с расписанием на каждый час на год вперед получается 24часа * 365 дней. А ну да, попутал, на 30 умножил лишный раз, получается 8760 строк на одно судно.
Ну в принципе не так плохо. При такой структуре легко посчитать любой период, но 1000 кораблей уже 8 млн строк.
Хотелось бы как-то оптимизировать структуру.

[sim3x]

petrun, Давйте начнем с актуализации ТЗ

Сколько полей и как заполняют судовладельцы?

Answer 1

[Gregory House]

Посмотрите как это делается в pms-системах (отели, да и вообще любое бронирование ресурсов). Это будет правильнее всего т.к. там учитываются практически все вариации ситуаций. Но там и сущностей будет больше. Тарифы, услуги, пакеты услуг, календари, приказы на изменение цен в тарифах, скидки, динамическое ценообразование, типы клиентов, сегментация и т.д. Это всё влияет на итоговую сумму в конечном счёте.

Answer 2

[Rsa97]

Если запросов немного, то можно хранить интервалы (тариф, вид, дата_начала, дата_конца, set(дни_недели), время_начала, время_конца, цена_часа). Но запросы могут быть сложными и длительными.

Comments

[petrun]

Да, я так и думал, но получается и правда как-то не очень оптимально.
Кстате при такой структуре как лучше хранить: все дни недели в одной строке или разбивать их и хранить 7 записей вместо одной?

[Rsa97]

petrun, Я бы сделал именно SET(0, 1, 2, 3, 4, 5, 6). Тогда можно день недели выбирать через FIND_IN_SET.

[Antonio Solo]

petrun, если вам эти тарифы потом использовать в расчетах, то конечно лучше хранить каждую цену одной записью

Answer 3

[rPman]

Каждый час - свой атрибут в таблице (т.е. 24-атрибута, а их значения в таблице - цены), ведь в запросах эти данные будут подставляться конкретным значением, а значит это можно делать генерируя сам запрос (это не повлияет на скорость его исполнения), зато не будет перегруженной структуры, лишних индексов и оверхеда на работу с ними = плюс к скорости и простоте разработки.

Comments

[petrun]

Не плохой вариант, только не очень понятно как обрабатывать переход от одного расписания к другому.
У каждого корабля может быть своя тарифная сетка.

[rPman]

petrun, не понял вопроса, тарифная сетка не кратна часу?
в таблице должны быть еще атрибууты - взрослый/детский, день недели и прочее