Вопрос по организации БД

← →
Николай Антонов (2010-01-05 11:43) [0]

Здравствуйте уважаемые мастера! Есть небольшая проблемма которую сам решить не могу, поэтому и обращаюсь к вам.
Пишу программу учета посещяемости оздоровительного центра. Мне необходимо организовать хранение персональных данных клиента и данных о посещениях(желательно MySQL). С персональными проблем нет, а вот дальше...
Суть проблемы: предположим Пупкин В.В может приходить в понедельник в 15:00, среду в 12:00, пятницу в 10:00. Как это правильно организовать на уровне БД, чтобы потом легко можно было делать выборки по дням и часам?
Первое что пришло на ум, это использовать типы ENUM и SET в MySQL. Все замечательно, создал поля days("пон", "вт", "ср"...) и hours("9:00", "10:00"...), выборки можно делать, но! Я не учел что нельзя сопоставить день с часом, данные в полях такого типа нельзя упорядочить.
Создавать 7 полей day1, day2, day3... и еще 7 hour1, hour2, hour3 мне кажеться каким-то неправильным решением.
Создавать отдельную таблицу-словарь со всеми возможными вариантами.... уж лучше поля...
Я не вижу пути решения. Казалось бы такая простая задача...
Пните в правильную сторону, куда копать, на вас последняя надежда.
Заранее благодарен.

← →
12 © (2010-01-05 16:00) [1]

неужели в MySQL нет типа (дата+время)

← →
Николай Антонов (2010-01-05 16:57) [2]

>[1]
Он есть, но это не то что мне нужно. Если упростить, мне нужно организовать хранение пари значений день_недели:час в одном поле, но так чтобы выборки можно было делать обычными DML-операторами (BLOB"ы отпадают). Начинаю приглядываться к PostgreSQL, там говорят есть возможность самому определять тип, но он мне кажеться слишком тяжеловестным для задачи такого рода.

← →
Jeer © (2010-01-05 17:11) [3]

Не очень понял в чем проблема, но иногда мне приходилось создавать отдельный справочник DateTimes, на который шли ссылки из заинтересованных таблиц.
Структура справочника была ориентирована на упрощение извлечения данных в ущерб простоты вставки (зависит от задач).

Т.е. TBL - таблица с полями

TBL_ID: longint
TBL_DATETIME: Date Time
и далее по потребностям
- рабочий/будний день
- праздничный день
- обычный/високосный год
- день недели
- день месяца
- день года
- день года по лунному календарю
и т.д.

← →
12 © (2010-01-05 17:28) [4]

не понял опять, чем тип (дата+время) не подходит

> день_недели:час в одном поле, но так чтобы выборки можно
> было делать обычными DML-операторами

в одном поле хранить тип (дата+время)
выделить из (дата+время) день_недели
выделить из (дата+время) час
можно обычными DML-операторами

фактически, получается изобретение велосипеда, а именно:
Сопоставим понедельнику 8:00 значение 1
Сопоставим понедельнику 14:00 значение 2
..
Сопоставим среде 20:00 значение 65

Уже все сопоставлено в типе (дата+время), а именно:
фактически это число, где dx в 1 день соответствует 1

← →
Николай Антонов (2010-01-05 17:53) [5]

2Jeer, спасибо за ответ, но, к сожалению, это тоже не то что я имел ввиду.
Я наверное слишком расплывчато описал проблему.
Мне не нужно работать с датой, мне нужно с днем недели.
Фактически как все это я думал реализовать в самом начале. Две таблички, в одной данные о клиентах, в другой, связанной, данные о посещениях(абонементах), т. е. дата начала, дата конца, дни(SET), часы(SET), т. д.
Далее я организовывал генерацию отчетов на период с такого-то по такое-то:
1) Обход циклом каждого дня в диапазоне дат.
2) Выборка из второй таблици всех записей у которых <счетчик цикла> between дата начала and дата конца.
3) Из полученного массива смотрим у кого в поле дни(SET) есть DayOfWeek(<счетчик цикла>).
4) Добавляем клиента в отчет.
Загвоздка в том, что я обнаружил что если например Пупкин В.В может приходить в понедельник в 15:00, среду в 12:00, пятницу в 10:00, и попытаться это закинуть в базу поле дни(понедельник, среда, пятницу), поле часы (15:00,12:00,10:00), собьеться соответствие, такое свойство у типа SET в MySQL, тоесть уже невозможно будет понять какому дню соответстует какой час. Собственно из-за этого весь сыр-бор, этот маленький ньюанс рушит всю логику работы.
У меня очень мало опыта по проектированию БД, возможно я пытаюсь изобрести велосипед, я незнаю, поэтому и сижу закопавшись в литературе и спрашиваю совета здесь.
Может мое решение в корне неверно? Направьте на путь истинный.

← →
Jeer © (2010-01-05 17:54) [6]

> 12 © (05.01.10 17:28) [4]
>
> не понял опять, чем тип (дата+время) не подходит

Я пояснил, что иногда важно ускорение выборки в ущерб вставки.
Могут быть очень занятные критерии выборки по дате, когда может требоваться даже решение системы уравнений. Возлагать это на сервер при выборке - может быть не рационально.

Впрочем, автору решать, что для него оптимальнее.
В любом случае ( с учетом возможностей сервера ) - все начинается с формата DateTime.

← →
Николай Антонов (2010-01-05 17:56) [7]

212
Спасибо, сейчас иду домой с работы, попытаюсь реализовать Ваш вариант.

← →
Jeer © (2010-01-05 17:59) [8]

Фиксируйте дату/время прибытия Пупкина в поле формата DateTime.
Далее, о чем уже было сказано выше, Вы можете извлекать записи с нужным диапазоном или с другими условиями. Надеюсь, Вы посмотрели какой квант времени предоставляет тип DateTime.

← →
Anatoly Podgoretsky © (2010-01-05 18:00) [9]

> Николай Антонов (05.01.2010 17:53:05) [5]

Практически любая СУБД может извлекать день недели из данных типа DateTime

хранить в БД только время посещения (DateTime),
для выборок подключить UDF, принимающую дату и возвращающую день недели и т. п.

Пон = 1
Вт = 2
и т.д.

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

← →
Николай Антонов (2010-01-05 23:05) [12]

Спасибо всем!
Решил хранить проблемные данные в DateTime (DAYNAME(), TIME()), подходит идеально.

> [12] Николай Антонов (05.01.10 23:05)

Если еще актуально, то я бы подумал о создании подробного графика/расписания работы вашего оздоровительного центра. Есть кабинеты или тренажеры (или что там у вас), у каждого наверное есть сеансы у которых есть время начала и продолжительность. Перед продажей абонементов на следующий месяц надо сгенерировать новый график и откорректировать его под реальность (праздники, профилактика оборудования, отпуска и т.п.) и продавать людям сеансы, у которых есть ИД-шник.

Вопрос по организации БД Найти похожие ветки