Armageddance
Новичок
Создаю сайт, основная функциональная часть которого посвящена записи по временному расписанию пользователей на определенные услуги. Хотелось бы чтобы система получилась гибкой, масштабируемой, на все случаи жизни, поэтому хочу сделать ее максимально эффективной и правильной.
Решил проконсультироваться со знатоками, чтобы сделать все грамотно и потом не тратить недели на исправление ранних ошибок.
Итак, суть. Есть ряд услуг/процедур/сервисов, которые решено реализовывать в виде типа данных дерево, например (в виде отдельных узлов - нодов):
Расписания. Расписания могут быть плавающие и фиксированные.
Фактически, каждый нод может содержать свой собственный профиль расписания, например бассейн может работать по фиксированному расписанию, где занятия проходят с 9:00 до 20:00 каждый час, и аналогично места 2 и 3 в женском зале парикмахерской, а Джакузи, мужской зал и места 1и 4 - по плавающему расписанию, где клиенты могут записаться в любое рабочее время и на любой промежуток.
Теперь, что касается организации базы хранения расписаний. Думаю организовать ее примерно следующим образом:
session_id - автоинкрементный индекс каждой новой записи, также в строке хранится в формате datetime время начала записи и время окончания записи на услугу и node_id, id нода с определенной услугой.
Таким образом каждая запись расписания будет уникальной.
На первый взгляд кажется, что все просто. Для плавающих расписаний вообще все кристально ясно, в любой момент можно добавить в таблицу запись с любыми желаемыми временами и нодом, а вот для фиксированных расписаний (например, где проходят занятия группами) не так все гладко. Подводный камень в следующем:
Допустим, мастеру понадобилось записать клиента на часовой промежуток времени например в 10:00 на 15-е число следующего месяца. Записал. А, например, 10-го числа следующего месяца администратор решил сместить расписание на 30 минут вперед, и теперь занятия происходят в 9 30 и в 10 30. Получается, в таком случае потребуется формировать фиксированные расписания на день два вперед, не дальше, чтобы не возникало коллизий со сменой расписаний или же автоматически переносить уже записанных клиентов к началу предыдущего или последующего сеанса.
Но а если там стоит ограничение на количество клиентов и больше мест нет, клиента перенести не получится, проблема.
А Какие еще подводные камни и сложности могут быть? И вообще, если кто понял о чем речь, может есть другой, более правильный способ организации структуры подобного сайта?
Решил проконсультироваться со знатоками, чтобы сделать все грамотно и потом не тратить недели на исправление ранних ошибок.
Итак, суть. Есть ряд услуг/процедур/сервисов, которые решено реализовывать в виде типа данных дерево, например (в виде отдельных узлов - нодов):
Расписания. Расписания могут быть плавающие и фиксированные.
Фактически, каждый нод может содержать свой собственный профиль расписания, например бассейн может работать по фиксированному расписанию, где занятия проходят с 9:00 до 20:00 каждый час, и аналогично места 2 и 3 в женском зале парикмахерской, а Джакузи, мужской зал и места 1и 4 - по плавающему расписанию, где клиенты могут записаться в любое рабочее время и на любой промежуток.
Теперь, что касается организации базы хранения расписаний. Думаю организовать ее примерно следующим образом:
session_id - автоинкрементный индекс каждой новой записи, также в строке хранится в формате datetime время начала записи и время окончания записи на услугу и node_id, id нода с определенной услугой.
Таким образом каждая запись расписания будет уникальной.
На первый взгляд кажется, что все просто. Для плавающих расписаний вообще все кристально ясно, в любой момент можно добавить в таблицу запись с любыми желаемыми временами и нодом, а вот для фиксированных расписаний (например, где проходят занятия группами) не так все гладко. Подводный камень в следующем:
Допустим, мастеру понадобилось записать клиента на часовой промежуток времени например в 10:00 на 15-е число следующего месяца. Записал. А, например, 10-го числа следующего месяца администратор решил сместить расписание на 30 минут вперед, и теперь занятия происходят в 9 30 и в 10 30. Получается, в таком случае потребуется формировать фиксированные расписания на день два вперед, не дальше, чтобы не возникало коллизий со сменой расписаний или же автоматически переносить уже записанных клиентов к началу предыдущего или последующего сеанса.
Но а если там стоит ограничение на количество клиентов и больше мест нет, клиента перенести не получится, проблема.
А Какие еще подводные камни и сложности могут быть? И вообще, если кто понял о чем речь, может есть другой, более правильный способ организации структуры подобного сайта?