| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Вопрос по организации БД [D7, 2000]
Николай Антонов © (2010-01-05 11:43:00)Здравствуйте уважаемые мастера! Есть небольшая проблемма которую сам решить не могу, поэтому и обращаюсь к вам.
Пишу программу учета посещяемости оздоровительного центра. Мне необходимо организовать хранение персональных данных клиента и данных о посещениях(желательно MySQL). С персональными проблем нет, а вот дальше...
Суть проблемы: предположим Пупкин В.В может приходить в понедельник в 15:00, среду в 12:00, пятницу в 10:00. Как это правильноорганизовать на уровне БД, чтобы потом легко можно было делать выборки по дням и часам?
Первое что пришло на ум, это использовать типы ENUM и SET в MySQL. Все замечательно, создал поля days('пон', 'вт', 'ср'...) и hours('9:00', '10:00'...), выборки можно делать, но! Я не учел что нельзя сопоставить день с часом, данные в полях такого типа нельзя упорядочить.
Создавать 7 полей day1, day2, day3... и еще 7 hour1, hour2, hour3 мне кажеться каким-то неправильным решением.
Создавать отдельную таблицу-словарь со всеми возможными вариантами.... уж лучше поля...
Я не вижу пути решения. Казалось бы такая простая задача...
Пните в правильную сторону, куда копать, на вас последняя надежда.
Заранее благодарен.
Sergey13 (2010-01-11 10:10:00) [1]> [12] Николай Антонов (05.01.10 23:05)
Если еще актуально, то я бы подумал о создании подробного графика/расписания работы вашего оздоровительного центра. Есть кабинеты или тренажеры (или что там у вас), у каждого наверное есть сеансы у которых есть время начала и продолжительность. Перед продажей абонементов на следующий месяц надо сгенерировать новый график и откорректировать его под реальность (праздники, профилактика оборудования, отпуска и т.п.) и продавать людям сеансы, у которых есть ИД-шник.
Николай Антонов (2010-01-05 23:05:00) [2]Спасибо всем!
Решил хранить проблемные данные в DateTime (DAYNAME(), TIME()), подходит идеально.
Юрий Зотов (2010-01-05 21:14:00) [3]Пон = 1
Вт = 2
и т.д.
Тогда день недели и время можно хранить хоть в разных полях (сортировать при выборке сначала по дню недели, потом по времени), хоть в одном поле
в дробном формате: целая часть - день недели, дробная часть - время (обычный Time). Во втором варианте немного усложняется визуализация, но это не проблема, все легко разруливается.
RWolf (2010-01-05 19:09:00) [4]хранить в БД только время посещения (DateTime),
для выборок подключить UDF, принимающую дату и возвращающую день недели и т. п.
Anatoly Podgoretsky (2010-01-05 18:00:00) [5]> Николай Антонов (05.01.2010 17:53:05) [5]
Практически любая СУБД может извлекать день недели из данных типа DateTime
Jeer (2010-01-05 17:59:00) [6]Фиксируйте дату/время прибытия Пупкина в поле формата DateTime.
Далее, о чем уже было сказано выше, Вы можете извлекать записи с нужным диапазоном или с другими условиями. Надеюсь, Вы посмотрели какой квант времени предоставляет тип DateTime.
Николай Антонов (2010-01-05 17:56:00) [7]212
Спасибо, сейчас иду домой с работы, попытаюсь реализовать Ваш вариант.
Jeer (2010-01-05 17:54:00) [8]
> 12 © (05.01.10 17:28) [4]
>
> не понял опять, чем тип (дата+время) не подходит
Я пояснил, что иногда важно ускорение выборки в ущерб вставки.
Могут быть очень занятные критерии выборки по дате, когда может требоваться даже решение системы уравнений. Возлагать это на сервер при выборке - может быть не рационально.
Впрочем, автору решать, что для него оптимальнее.
В любом случае ( с учетом возможностей сервера ) - все начинается с формата DateTime.
Николай Антонов (2010-01-05 17:53:00) [9]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, тоесть уже невозможно будет понять какому дню соответстует какой час. Собственно из-за этого весь сыр-бор, этот маленький ньюанс рушит всю логику работы.
У меня очень мало опыта по проектированию БД, возможно я пытаюсь изобрести велосипед, я незнаю, поэтому и сижу закопавшись в литературе и спрашиваю совета здесь.
Может мое решение в корне неверно? Направьте на путь истинный.
12 (2010-01-05 17:28:00) [10]не понял опять, чем тип (дата+время) не подходит
> день_недели:час в одном поле, но так чтобы выборки можно
> было делать обычными DML-операторами
в одном поле хранить тип (дата+время)
выделить из (дата+время) день_недели
выделить из (дата+время) час
можно обычными DML-операторами
фактически, получается изобретение велосипеда, а именно:
Сопоставим понедельнику 8:00 значение 1
Сопоставим понедельнику 14:00 значение 2
..
Сопоставим среде 20:00 значение 65
Уже все сопоставлено в типе (дата+время), а именно:
фактически это число, где dx в 1 день соответствует 1
Jeer (2010-01-05 17:11:00) [11]Не очень понял в чем проблема, но иногда мне приходилось создавать отдельный справочник DateTimes, на который шли ссылки из заинтересованных таблиц.
Структура справочника была ориентирована на упрощение извлечения данных в ущерб простоты вставки (зависит от задач).
Т.е. TBL - таблица с полями
TBL_ID: longint
TBL_DATETIME: Date Time
и далее по потребностям
- рабочий/будний день
- праздничный день
- обычный/високосный год
- день недели
- день месяца
- день года
- день года по лунному календарю
и т.д.
Николай Антонов (2010-01-05 16:57:00) [12]>[1]
Он есть, но это не то что мне нужно. Если упростить, мне нужно организовать хранение пари значений день_недели:час в одном поле, но так чтобы выборки можно было делать обычными DML-операторами (BLOB'ы отпадают). Начинаю приглядываться к PostgreSQL, там говорят есть возможность самому определять тип, но он мне кажеться слишком тяжеловестным для задачи такого рода.
12 (2010-01-05 16:00:00) [13]неужели в MySQL нет типа (дата+время)
| |
