Как структурировать базу данных MySQL для онлайн записи?

Question

[Alex]

Есть цель сделать онлайн запись, хочется услышать мнения по структуре базы MySQL для онлайн записи, т.е. как хранить данные чтобы удобно их обрабатывать.
Интервал записи может меняться (10, 20, 30, 40, 50, 60, 90, 120 мин), каждый день может быть любой интервал рабочего времени (Пн с 8 до 17 (обед с 12 до 13), Вт с 10 до 16 (без обеда) и тд).
Теряюсь в мыслях как структурировать всё по таблицам и на какие поля их поделить. Нужно хранить и общие настройки интервала и графика работы и в то же время индивидуальные настройки для каждого дня (если график меняется в этот день или вовсе выходной). Вообщем буду рад любым подсказкам и мыслям по более менее грамотной структуре таблиц.

Comments

[Владимир]

Под "онлайн записью" имеется в виду запись на получение каких-то услуг? Тогда нужно конкретизировать какие именно данные хотите хранить и какой будет объем (подозреваю что мизерный -- порядка десятков тысяч записей в год, но мало ли). Интервалы и график работы это самое простое, особенно если нет необходимость упарываться в нормализацию.

[Alex]

Владимир, про услуги речи не идёт вопрос записи клиентов без услуг. Тупо есть запись с некоторой информацией. Вопрос именно как структурировать бд по дням и по самим записям, чтобы легко обрабатывать и записывать новые данные.
Визуализировано это просто календарь на JS с днями, в каждом дне есть секции по 10 мин от начала раб. дня до конца с учетом обедов. Можно выбрать например три секции по 10 минут (30 мин) для одной записи клиента. В данных к записи будет что то вроде заметки текстовой для данных клиента и какую услугу оказываем.
Но как это все хранить, чтобы это всё было удобно и грамотно для загрузки на страницу и для обработки и хранения, пока не укладывается в голове.

[ThunderCat]

Alex,

про услуги речи не идёт

будет что то вроде заметки текстовой для данных клиента и какую услугу оказываем.

Чет как-то не совпадает у вас...

[Владимир]

Alex, и в чем проблема? День разбит на секции, значит нумеруем секции. В одной таблице держим расписание вида:
Дата, Номер секции начала интервала, Номер секции конца интервала, Тип интервала.

Например:
02.03.2021, 1, 23, Прием клиентов
02.03.2021, 24, 29, Обед.
02.03.2021, 30, 53, Прием клиентов

Во вторую пишем записи в виде:
Дата, Номер секции начала интервала, Номер секции конца интервала, Клиент (ссылка на таблицу клиентов), Тип услуги (ссылка на таблицу услуг), Кто оказывает (при необходимости, ссылка на таблицу работников)

Например:
02.03.2021, 11, 13, @барабас, @флагелляция, @мальвина

Если отойти от секций, то в "Начало интервала" и "Конец интервала" можно просто писать время.

Самое главное, это понять что хранение данных, их представление в программе и способ их демонстрации пользователю это три совершенно разные вещи. Храним так, чтобы было удобно делать выборки и расширять в дальнейшем функционал программы, представляем в программе так, чтобы было удобно реализовывать бизнес-логику, показываем пользователю так, чтобы было удобно щелкать мышкой. Разделяем все по уровням абстракции и спокойно работаем.

[VitalyChaikin]

Alex, на сколько я понял задачу: данные храним в двух таблицах;
Первая содержит условно: ДатаВремя1, ДатаВремя2, Событие, Другие поля
Вторая содержит разбиение дня на интервалы:

Дата0, ДатаВремя1, ДатаВремя2, НазваниеИнтервала, Другие поля

И если необходимо получить информацию, можем выбрать ее из первой таблицы; Этот набор данных можем разбить на интервалы как после выборки из первой таблицы, так и до (но тогда нужен другой запрос) Кроме этого, легко отладить - так как обработка выборки после и до, должны совпадать (а если какой то вариант не работает, всегда есть резервный)

[Alex]

ThunderCat, всё совпадает если брать в целом контекст сказанного. Текстовая заметка к записи и Услуга ни одно и то же. Отдельно как таковой услуги не будет прикрепляться к записи, будет просто доп. поле у записи с текстом где в свободной форме указывается любая инфа о клиенте.

Answer 1

[Алексей Смирнов]

Задача хитрая в том плане, что будет первое время ускользать из рук. Т.е. вам несколько раз придется улучшать логику приложения, пока придете к нужному результату. Но не бойтесь, начните с малого. Базе данных очень важно знать - какие данные вы будете хранить и в каком виде от нее получать. Остальное она все сделает сама.

Поэтому начнем с самого простого - таблицы для хранения самой записи. Таблицу назовем `reg` от слова `registration` (Регистрация). Поле `id` - ключевое. Поле `datetime` - хранит дату и время записи. Поле `info` - произвольная текстовая информация, не длиннее 255 символов.

CREATE TABLE `reg` (
	`id` INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'id записи',
	`datetime` DATETIME NULL DEFAULT NULL COMMENT 'Дата и время записи',
	`info` VARCHAR(255) NOT NULL DEFAULT '' COMMENT 'Текстовая информация о записи' COLLATE 'utf8mb4_unicode_ci',
	PRIMARY KEY (`id`),
	INDEX `datetime` (`datetime`)
)
COMMENT='Регистрация'
COLLATE='utf8mb4_unicode_ci'
ENGINE=InnoDB;

Попробовать повводить данные в таблицу можете здесь, например через программу HeidiSQL:
- сервер: habr.atou.ru
- порт: 3311
- пользователь: habr_95659
- пароль: 9D4z3R4b
- база данных: habr_952563

Если захотите продолжить. Помогу создать следующие таблицы.