Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2008.04.20;
Скачать: [xml.tar.bz2];

Вниз

Перекрытие временных периодов   Найти похожие ветки 

 
Paradise ©   (2007-11-26 12:19) [0]

Здравствуйте!
Подскажите,пожалуйста,а то уже измучилась просто..
Есть БД в Access.С помощью ADO подключена в Delphi.
Там есть поле Период_работы,в нем время в течение которого инженер выполнял работу,например с 14:00 до 15:00 26 ноября 2007г.
Подскажите,как реализовать перекрытие периодов,чтобы у определенного инженера был не повторяющийся период работы в определенный день недели?
Нужен именно алгоритм кода и куда его вставить.


 
Сергей М. ©   (2007-11-26 12:29) [1]


> есть поле Период_работы


Оно там откуда взялось ?
Это ты создал такое поле или оно досталось тебе по наследству ?
Я в смысле - кто разработчик структуры базы ?


 
Paradise ©   (2007-11-26 12:35) [2]

Саму структуру БД составляла я.
В принципе,думаю логичнее сделать два поля "Начало работы" и "Конец работы",но всё равно как реализовать перекрытие непонятно...


 
Paradise ©   (2007-11-26 12:46) [3]

Сама структра главной таблицы это:
Дата--Клиент--Адрес--Описание проблемы--Мастер--Период_работы

Связи по полям клиенты,мастер и период_работы.


 
Johnmen ©   (2007-11-26 12:52) [4]


> Подскажите,как реализовать перекрытие периодов,чтобы у определенного
> инженера был не повторяющийся период работы в определенный
> день недели?

Можно ещё раз. Для тех, кто ничего не понял.


 
Сергей М. ©   (2007-11-26 12:56) [5]


> логичнее сделать два поля "Начало работы" и "Конец работы"


Угу.
Что угодно, но только не строковое представление данных о периоде.

Два поля типа DATETIME (дата+время начала и окончания периода) вместо полей  "Дата" и "Период_работы" намного облегчат решение задачи, тем более с учетом БД Access.

Переделывай, потом и разговор будет)


 
Paradise ©   (2007-11-26 12:58) [6]

Ну например,есть инженер Петров,который 26 ноября 2007 года ремонтировал принтер с 14:30 до 15:30 у клиента ООО "Ромашка".Он же не может уже с 14:30 до 15:30 26 ноября 2007 года ремонтировать принтер в ООО "Самолет".
А у меня в базе получает,что может...


 
Сергей М. ©   (2007-11-26 13:01) [7]


> Johnmen ©   (26.11.07 12:52) [4]
>
>


Я так понял, что задача сводится к реализации неких проверок, не допускающих фиксацию выполнения мастером более чем одного "заказа" в любой момент времени.


 
Paradise ©   (2007-11-26 13:03) [8]


> Два поля типа DATETIME (дата+время начала и окончания периода)
> вместо полей  "Дата" и "Период_работы" намного облегчат
> решение задачи, тем более с учетом БД Access.


Ну дата то в любом случае останется.Это дата поступления заявки и привязана к календарю.
А время начала и окончания периода лучше делать в одном поле?Или проще разбить на два?


 
Сергей М. ©   (2007-11-26 13:06) [9]


> Ну дата то в любом случае останется.Это дата поступления
> заявки


Ну тогда уж и оно должно быть типа DATETIME - время поступления заявки в течение дня, наверняка, тоже понадобится.


> время начала и окончания периода лучше делать в одном поле?


Ты уже сделала в одном поле)
О том ведь и речь, чтобы разбив его на два избавить тем самым себя от грядущего геморроя)


 
Сергей М. ©   (2007-11-26 13:11) [10]


> Paradise


А это что вообще такое - табель учета раб.времени что ли ?


 
Paradise ©   (2007-11-26 13:14) [11]


> Я так понял, что задача сводится к реализации неких проверок,
>  не допускающих фиксацию выполнения мастером более чем одного
> "заказа" в любой момент времени.

Да,имеенно эта задача.Но инжнеров то несколько,поэтому непонятно как привязать алгоритм выполнения проверки и к календарю,и к инженеру...


> Ну тогда уж и оно должно быть типа DATETIME - время поступления
> заявки в течение дня, наверняка, тоже понадобится.

Ну у меня там пока просто дата,которая выбирается из выпадающего календаря.


> Ты уже сделала в одном поле)
> О том ведь и речь, чтобы разбив его на два избавить тем
> самым себя от грядущего геморроя)


Это да,разбить то их просто...только разбивать пока не стали,т.к. непонятно,что дальше...


 
Sergey13 ©   (2007-11-26 13:14) [12]

> [0] Paradise ©   (26.11.07 12:19)
> Там есть поле Период_работы,в нем время в течение которого
> инженер выполнял работу,например с 14:00 до 15:00 26 ноября
> 2007г.

Может я чего не понимаю, но как это вообще возможно? Что за тип у поля?


 
Paradise ©   (2007-11-26 13:17) [13]


> Сергей М


Нет,это что-то вроде автоматизированного рабочего места администратора сервисного отдела.
Т.е. главная форма это Заявка от клиента,которую заполняет администратор(наименование клиента,адрес,описание проблемы).А потом он же её обрабатывает(указывает необходимую услугу-ремонт,диагности и пр.) и подбирает мастера в зависимости от его "незанятости".


 
Paradise ©   (2007-11-26 13:19) [14]


> Sergey13 ©


> Может я чего не понимаю, но как это вообще возможно? Что
> за тип у поля?

Пока что текстовое,но это неправильно.Будет дата/время.
На счет возможности не знаю,но как-то это должно реализовываться?


 
Sergey13 ©   (2007-11-26 13:25) [15]

> [11] Paradise ©   (26.11.07 13:14)
> Да,имеенно эта задача.Но инжнеров то несколько,поэтому непонятно
> как привязать алгоритм выполнения проверки и к календарю,
> и к инженеру...

А чего тут думать? Перед вводом новой записи в календаре проверяешь максимальную дату-время окончания работ текущего работника. Начало работы в новой записи должно быть больше или совпадать.


 
umbra ©   (2007-11-26 13:27) [16]


> .А потом он же её обрабатывает(указывает необходимую услугу-
> ремонт,диагности и пр.) и подбирает мастера в зависимости
> от его "незанятости".

можно добавить мастерам признак "занят/не занят"


 
Paradise ©   (2007-11-26 13:33) [17]


> Sergey13 ©


> А чего тут думать? Перед вводом новой записи в календаре
> проверяешь максимальную дату-время окончания работ текущего
> работника. Начало работы в новой записи должно быть больше
> или совпадать.

Я так понимаю,что проверка должна происходить при нажатии на кнопку "Новая запись".
А как хотя бы приблизительно должен выглядеть код?


 
Anatoly Podgoretsky ©   (2007-11-26 13:52) [18]

> Sergey13  (26.11.2007 13:25:15)  [15]

В принципе не верно, допустим согласовано с клиентом время с 14 до 15, а время и до и после свободно.


 
Sergey13 ©   (2007-11-26 13:53) [19]

> [17] Paradise ©   (26.11.07 13:33)
> Я так понимаю,что проверка должна происходить при нажатии
> на кнопку "Новая запись".
Скорее перед сохранением новой записи в БД.

> А как хотя бы приблизительно должен выглядеть код?

select max(datetime_field) as max_dt from table_name


 
Anatoly Podgoretsky ©   (2007-11-26 13:54) [20]

> Paradise  (26.11.2007 13:33:17)  [17]

Я думаю тут надо интерфейс менять, что то типа Microsoft Project, что бы сразу видно было занятость, тогда и проверять не надо. А интервалы могут быть и пересекаемыми, что если мастер закончит работу на 30 минут раньше, ему что курить?


 
Sergey13 ©   (2007-11-26 14:03) [21]

> [18] Anatoly Podgoretsky ©   (26.11.07 13:52)

Просто проверка несколько усложняется и все. Кроме того, таких подробностей автором не озвучивалось.

Еще вариант. Сформировать таблицу рабочего времени инжененера на все рабочие дни. Смену разбить на "стандартные" интервалы с эмпирически подобранной длительностью (например полчаса). Каждой заявке давать нужное количество этих интервалов. Очень наглядно будет видна занятость каждого работника.


 
Paradise ©   (2007-11-26 14:34) [22]


> Еще вариант. Сформировать таблицу рабочего времени инжененера
> на все рабочие дни. Смену разбить на "стандартные" интервалы
> с эмпирически подобранной длительностью (например полчаса).
>  Каждой заявке давать нужное количество этих интервалов.
>  Очень наглядно будет видна занятость каждого работника.
>

Хороший вариант.Но тут будет тогда не сам интервал,а просто количество часов отработанных инженером.И тогда администратор не сможет реализовать алгоритм проверки "занятости" в определенный момент времени.


 
Sergey13 ©   (2007-11-26 14:40) [23]

> [22] Paradise ©   (26.11.07 14:34)
> Но тут будет тогда не сам интервал,а просто количество часов отработанных инженером.

Почему?
Например таблица с рабочим временм.
1. 9-00 ... 9-30
2. 9-30 ... 10-00
3. 10-00 ... 10-30
и т.д.

Заявке №111 соответствует интервал 1 (т.е. полчаса), заявке №222 - интервалы 2 и 3 (т.е. 1 час).
Иными словами определенное время работы одного определенного работника будет привязано строго к одной определенной заявке. Т.е. пересечения не получится автоматически - если интервал рабочего времени занят, его нельзя взять повторно.


 
Paradise ©   (2007-11-26 14:51) [24]


> Заявке №111 соответствует интервал 1 (т.е. полчаса), заявке
> №222 - интервалы 2 и 3 (т.е. 1 час).
> Иными словами определенное время работы одного определенного
> работника будет привязано строго к одной определенной заявке.
>  Т.е. пересечения не получится автоматически - если интервал
> рабочего времени занят, его нельзя взять повторно.


Вот сейчас у меня связь таблицы Инженеры и График_работы один-ко-многим.
Нужно прописывать где-то дополнительно,что в определенный день интервал с 9:00 до 9:30 уже занят?Просто мне кажется,что по умолчанию всё равно будет пересечение.Простите,если не совсем поняла вас..


 
Сергей М. ©   (2007-11-26 15:27) [25]


> подбирает мастера в зависимости от его "незанятости"


Любопытно, откуда Администратору знать, сколько времени потребуется мастеру на выполнение конкретной клиентской заявки ?

На то он и Мастер, чтобы имея соответствующие знания и навыки определить времяемкость и/или ресурсоемкость той или иной потенциальной работы.

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


 
Sergey13 ©   (2007-11-26 15:27) [26]

> [24] Paradise ©   (26.11.07 14:51)
> Нужно прописывать где-то дополнительно,что в определенный день интервал с 9:00 до 9:30 уже занят?
Да. Нужна еще 1 таблица, вернее 2.
1. Интервалы рабочего времени (справочник)
id, Time_begin, Time_end
тут просто перечислены все возможные интервалы времени за 1 сутки. За единицу нужно принять минимально возможный (официально) интервал времени необходимый для выполнения самой простой работы.

2. Интервалы рабочего времени РАБОТНИКОВ
id, id_rabotnika, work_date, id_intervala
Т.е. тут нужно указать в какие часы работает инженер, но выразить это не в часах/минутах, а в заранее заданных единицах времени - тех самых интервалах. Она заполняется однократно в [полу]автоматическом режиме в конце периода на период вперед (например на месяц), исходя из графика работы, выходных и т.д.

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

ЗЫ: Я напомню, что это только вариант решения задачи, а не настоятельная рекомендация.


 
Paradise ©   (2007-11-26 15:45) [27]


> Любопытно, откуда Администратору знать, сколько времени
> потребуется мастеру на выполнение конкретной клиентской
> заявки ?

Нее,тут имеется в виду что в заявке будет стоять сначала только время начало работы,а конец будет проставляться потом.
Поэтому "незанятость" будет определяться исходя из начала работы.


> Sergey13 ©

Спасибо.Попробуем вечером такую реализацию.


 
Anatoly Podgoretsky ©   (2007-11-26 16:43) [28]

> Paradise  (26.11.2007 15:45:27)  [27]

В таком случае ситуация проще, это или интервалы ниже этого времени, или выше если стоит время окончания.


 
Paradise ©   (2007-11-26 16:54) [29]


> Anatoly Podgoretsky ©   (26.11.07 16:43) [28]

А как это описать?



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2008.04.20;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.54 MB
Время: 0.042 c
15-1205146184
Raven
2008-03-10 13:49
2008.04.20
Изучение дополнительно еще одного языка


15-1205082091
who
2008-03-09 20:01
2008.04.20
Игорь Шевченко


2-1206087017
Новичек
2008-03-21 11:10
2008.04.20
Динамическое создание методов.


15-1204929909
oxffff
2008-03-08 01:45
2008.04.20
Всех дам с 8 Марта поздравляем


2-1205995715
Fr1K
2008-03-20 09:48
2008.04.20
DBLookupComboBox1





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский