теория

← →
gestern (2003-11-29 18:24) [0]

Нужен совет бывалых товарищей. Делаю базу для одной организации в которой необходима запись клиентов. Запись производится с 9.00 до 20.00 с промежутком в 30 минут. Запись в 11 кабинетов. Таким образом в день 11*22=242 записей. У меня проблема, я не знаю каким образом оптимально организовать запись. Хотел было заполнить поля которые отвечают за дату и время на десять лет вперёд и забыть. После того как начал заполнять таблицу понял что так не пойдёт, заполнение происходило автоматически, за ночь заполнились поля только на год вперёд, база разрослась и начала
притормаживать. Сейчас хочу сделать так, что-бы при запуске проги
проверялось наличие записей на 2 недели вперёд, и в случае их
отсутствия поля заполнялись на 2 ндели вперёд ине более, этого им будет достаточно.
А вопрос в том есть ли стандартные подходы к проблеме, прошу подсказать оптимальное решение.

← →
Anatoly Podgoretsky © (2003-11-29 18:32) [1]

Ну так в чем проблема в предикате Where укажи текущую дату + 14 дней

← →
gestern (2003-11-29 19:47) [2]

> Ну так в чем проблема в предикате Where укажи текущую дату
> + 14 дней

Извините за нескромный вопрос, но что такое предиката.

← →
Anatoly Podgoretsky © (2003-11-29 19:51) [3]

Часть SQL выражения не относящая к команде, оператор.
Можно найти последнею дату и затем добавить новые записи. Можно посмотреть записи за последнии 14 дней.

Все же не совсем понятно, что значит:
Хотел было заполнить поля которые отвечают за дату и время на десять лет вперёд и забыть
Обрисуй точнее, что ты хочешь сделать.
Я в свое время решал похожую задачу. Я вставлял только те промежутки времени, на которые имелись записанные пациенты. Остальные промежутки считались свободными.
Типа 1 запись:
ID, Рабочее место, Начало, Конец.
К этой записи через foreign key относилась более хитрая запись о том, что это за прием и к какому пациенту он относится.
Основной задачей был поиск "дырок" с помощью SQL.
Если у тебя время на прием фиксированное , то задача еще более упрощается.
Вспомнил!
Я генерил промежутки рабочего времени (расписание врачей), а затем дробил их.
То есть вначале имеется 30 записей для 11 кабинетов на весь месяц. Это всего 330 записей. Но каждая представляет собой отрезок на все рабочее время. (С учетом 2-х смен может быть в 2 раза больше). Затем при записи эти отрезки дробятся (запись об отрезке удаляется и вместо нее вставляется 3 записи (свободный промежуток "до", "прием", свободный промежуток "после"). Если визит нужно отменить, удаляются 3 записи и заменяются одной (свободный промежуток). Эти два действия(раздробить или "склеить" выполнялись двумя хранимыми процедурами).
При попытке раздробить промежуток, помеченный, как визит, программа сразу говорит о невозможности этого. В результате все работало очень быстро и хранился минимум записей в таблицах. К тому же можно было генерить расписание всех врачей на месяц вперед создав всего несколько сотен очень информативных записей об их "свободных" промежутках.
Еще кайф такого решения в том, что промежутки я отображал с помощью компонента TDBChart разными цветами сразу для всего кабинета (кажется, серия типа TGant):

Иванов <---->.......<-->.......<----->
Петров ........<--------->..<-------->
Сидоров ......<-->....................

Используя событие TDBChart при клике на любой отрезок, я вызывал диалог записи на прием на это время или удаления визита (если ошибочно назначили что-то не то или отменили визит)

Тогда я нашел это очень удачным решением такой задачи. И главное - быстрым как с точки зрения генерации расписаний, так и с точки зрения всех остальных SQL-дел.

теория Найти похожие ветки