Непересекающиеся периоды в БД.

← →
Курдль © (2006-09-21 10:15) [0]

Кто имеет опыт или светлые мысли по изящной реализации непересекающихся периодов и готов ими поделиться?
Я имею в виду сущность БД "ПЕРИОД", имеющую дату-время начала и дату-время окончания с таким учетом, чтобы периоды шли последовательно и ни один из периодов не пересекался с любым другим.
Ясно, что все выполнимо на триггерах. Это тривиально... А иначе?

ЗЫ: Понимаю, что вопрос для форума "базы", но на этом иногда мысли свежее :)

← →
Danilka © (2006-09-21 10:17) [1]

таблица, которая содержит только дату начала периода.
а дата конца периода - это дата начала след. периода -1.

← →
Курдль © (2006-09-21 10:19) [2]

> Danilka © (21.09.06 10:17) [1]
> таблица, которая содержит только дату начала периода.
> а дата конца периода - это дата начала след. периода -1.

Ага! Согласен! Есть такое дело. А если периоды чередуются, напр. нужный/ненужный или работа/отдых, а нужны только первые из них, тогда половина записей окажутся лишними?..

← →
Ганна Юхимівна (2006-09-21 10:23) [3]

> тогда половина записей окажутся лишними?..

Ну и черт с ними... :)

← →
Danilka © (2006-09-21 10:43) [4]

[2] Курдль © (21.09.06 10:19)
честно говоря, не понял нифига :)
делаешь, навскидку, такую вьюху на таблицу периодов с одним полем:

create view v_period (begin_date, end_date) as
select
p.begin_date,
(select min(begin_date)-1 from period p2 where p2.begin_date > p.begin_date) end_date
from period p
/

И работаешь с v_period, как с таблицей периодов.

← →
Johnmen © (2006-09-21 10:52) [5]

> Курдль © (21.09.06 10:15)
> Кто имеет опыт или светлые мысли по изящной реализации непересекающихся
> периодов и готов ими поделиться? Я имею в виду сущность
> БД "ПЕРИОД", имеющую дату-время начала и дату-время окончания
> с таким учетом, чтобы периоды шли последовательно и ни один
> из периодов не пересекался с любым другим.Ясно, что все
> выполнимо на триггерах. Это тривиально... А иначе?

Хм... Хочется нетривиально-громоздко-медленно? :)
Кстати, а что значит "на триггерах"? Что на них? Проверки? Что ещё?

← →
Курдль © (2006-09-21 11:00) [6]

> Johnmen © (21.09.06 10:52) [5]
> Кстати, а что значит "на триггерах"? Что на них? Проверки?
> Что ещё?

Да, конечно, проверки. Громоздко не хочется.
Задача простая, типа "исполнитель может в один момент времени работать только над одним заданием". Задача не горящая, - есть время подумать и посмаковать :)

← →
Sergey13 © (2006-09-21 11:05) [7]

> [6] Курдль © (21.09.06 11:00)

К
> [1] Danilka © (21.09.06 10:17)

Добавить поле - идентификатор периода.

← →
Danilka © (2006-09-21 11:13) [8]

[7] Sergey13 © (21.09.06 11:05)
В смысле?
Фразу "... А если периоды чередуются, напр. нужный/ненужный или работа/отдых ..." следует понимать так:

create view v_period (period_type, begin_date, end_date) as
select
p.period_type,
p.begin_date,
(select min(begin_date)-1 from period p2 where p2.period_type = p.period_type and p2.begin_date > p.begin_date) end_date
from period p
/

?

← →
Курдль © (2006-09-21 11:28) [9]

> Danilka © (21.09.06 11:13) [8]

Да, для описанной мной задачи хорошее решение.
Однако, если исполнителей много, то от сущности ПЕРИОД придется отказаться (тогда периоды смогут пересекаться) в пользу сущности РАБОТА. Последняя тоже должна иметь атрибуты "начало" и "конец" и не пересекаться по периодам начало - конец.
В последнем случае предыдущее решение будет выглядеть некузяво :)
"ТИП_РАБОТЫ = НЕРАБОЧИЙ" :)

← →
Sergey13 © (2006-09-21 11:41) [10]

> [9] Курдль © (21.09.06 11:28)

Не очень понятно, что тебе надо. Возможно нужна связь "ПЕРИОДЫ выполнения РАБОТ ИСПОЛНИТЕЛЯМИ"? Просто ПЕРИОД сам по себе ни о чем не говорит, РАБОТА - тоже, ибо ей могут в разное время могут заниматься разные люди, одновременно или по очереди. ИСПОНИТЕЛИ также могут занимться в разное время разными работами.
Или я не въехал?

← →
Johnmen © (2006-09-21 11:48) [11]

> Курдль © (21.09.06 11:28) [9]
> > Danilka © (21.09.06 11:13) [8] Да, для описанной мной
> задачи хорошее решение.

Т.е. в следовании периодов не бывает пробелов в принципе?
Тогда в свете "дату-время начала и дату-время окончания" неясно, что является минимальной неделимой единицей отсчёта...:)

← →
Курдль © (2006-09-21 11:52) [12]

> Sergey13 © (21.09.06 11:41) [10]
Или я не въехал?

Я просто невнятно объяснил.
Суть субмодели такая. Есть ЗАДАЧИ, РАБОТЫ и ИСПОЛНИТЕЛИ.
В один момент времени один исполнитель может работать только с одной задачей. Необходимо фиксировать начало работ над задачей и окончание работ над ней, и хранить историю работ над задачами.

← →
Romkin © (2006-09-21 11:58) [13]

> Задача не горящая, - есть время подумать и посмаковать :
> )
>

Угу. Типовая задача - есть ресурс, который может быть использован в каждый период времени только один раз. Решал я эту задачу, еще в прошлом веке :)
И решение у меня не совсем по периодам: есть день (дата) и есть справочник сеансов, в корорые доступен объект (ID, аббр, наименование). Причем ID у нас - numeric(4,2) и в него пишется время :) Ну небыло тогда TTime... В принципе, можно что угодно, лишь бы порядок задавался.
И есть вспомогательная таблица, в которой отдельными записями для каждого объхекта для каждой даты и для каждого сеанса пишется ссылка, кто использует (если использует). Это помимо основной, для которой мастером является ресурс и для него записано, кто когда пользует.
Остальное - триггеры и процедуры...

← →
Sergey13 © (2006-09-21 12:00) [14]

> [12] Курдль © (21.09.06 11:52)

Т.е. РАБОТА - это некий процесс, выполняемый в рамках ЗАДАЧИ определенным ИСПОЛНИТЕЛЕМ?
Если да, то
[1] Danilka © (21.09.06 10:17)+ идентификатор работы должно работать.

← →
Курдль © (2006-09-21 12:04) [15]

> Romkin © (21.09.06 11:58) [13]
> Решал я эту задачу, еще в прошлом веке :)
> И решение у меня не совсем по периодам: есть день (дата)
> и есть справочник сеансов, в корорые доступен объект

Такую задачу я тоже решал в прошлом веке :)
Заказчик - строитель автоматизировал проектную деятельность. Периодом квантования назначил день. Тогда все и вправду очень красиво решалось. Причем дни задачи двигались, как "бусинки на леске", перескакивали через выходные, рекурсивно двигали зависимые задачи и т.п.
Сейчас идея немного иная.

← →
Romkin © (2006-09-21 12:15) [16]

Курдль © (21.09.06 12:04) [15] У меня сеансы делят день на части, а не являются днями. Так что примерно так и получается, основная идея - никто не будет ставить с точностью до минуты, есть кванты времени. На практике так и получается: основная занятость - 2-4 сеанса в день выделено, вспомогательная - там и 24 может быть. И есть еще занятость "вне сеансов" - там четко указывается время, но во вспомогательной таблице все равно отмечаются только сеансы, которые туда попадают.

← →
Курдль © (2006-09-21 12:25) [17]

> Romkin © (21.09.06 12:15) [16]

Мысль понятная. Однако, вариант с квантованием чрезвычайно удобен при планировании, но не при регистрации факта.
Например, если период квантования - час, а исполнитель закончил работу в 13:30:00, то какой час вписать, как последний? А какаой - как первый для начала следующей работы, если она реально началась в 13:30:01?

← →
Romkin © (2006-09-21 12:36) [18]

А, у тебя по фактическому времени? Тады да, не слишком удобно. У меня есть, как я говорил, вспомогательные, со временем, и тогда, если сеансы в 13:00 и в 14:00, то соответственно, во вспомогательную пишутся они, а в факте - реальное время. То есть, во вспомогательной сеанс 13:00 был занят одной задачей, а 14:00 - уже другой. Это позволяет легко выяснить, занят ли ресурс. А в факте - реально окончание одной в 13:30, начало другой - в 13:31. Но это вряд ли тебе подойдет: у меня-то все считается именно по сеансам, а что там по факту - пофиг :)

← →
Desdechado © (2006-09-21 13:06) [19]

Danilka © (21.09.06 10:17) [1]
Если периоды непоследовательные? Например, 10-12, 16-18, а между ними пусто. Можно и пустоту периодом оформить, но ее может оказаться чрезвычайно много, что неэффективно.

> Desdechado © (21.09.06 13:06) [19]
> Danilka © (21.09.06 10:17) [1]
> Если периоды непоследовательные? Например, 10-12, 16-18,
> а между ними пусто. Можно и пустоту периодом оформить,
> но ее может оказаться чрезвычайно много, что неэффективно.
>

Ага! Я об этом говорил в Курдль © (21.09.06 10:19) [2]
Не сказал бы, что "чрезвычайно много", но ровно в 2 раза больше, чем нужно - это точно :)

Значицца так. Я принял такое решение.
В связи с тем, что исполнителям (да и вообще никому) править дату начала и окончания работ никто давать не собирается (а лишь зафиксить факт начала работы и факт окончания), контроль за пересекаемостью периодов отодвинут на 2-ой план (оформим триггером). Важнее, чтобы исполнители не могли иметь более одной незакрытой работы. Поэтому я сделал в таблице РАБОТА составной ключ из полей "ID задачи" и "дата окончания". При инициации новой записи в последнее прописывается константа типа "00.00.00" или "99.99.99" (не важно). При окончании работы в это поле записывается фактическая дата/время. Вот такая воспаленная фантазия :)

> составной ключ из полей "ID задачи"

читать, как "составной ключ из полей "ID исполнителя"

> Johnmen © (21.09.06 15:57) [23]

"Дура" - "не дура", а $100 в день имею (с)

Описанная мной модель позволяет реализовать целостное хранение данных в соответствии с системными бизнес-требованиями. Что и требовалось доказать.

> Курдль © (21.09.06 16:04) [24]

Ну и славно.
Только почему-то я думаю, что будут проблемы. И всплывут они не сразу...
Не пытай меня конкретикой, просто попомни...:)

>[19] Desdechado(c) 06-09-21 13:06
>Danilka c (21.09.06 10:17) [1]
>Если периоды непоследовательные? Например, 10-12,
>16-18, а между ними пусто. Можно и пустоту
>периодом оформить, но ее может оказаться
>чрезвычайно много, что неэффективно.

Хм. Про дырки я не думал. :)

> Ага! Я об этом говорил в Курдль © (21.09.06 10:19) [2]
> Не сказал бы, что "чрезвычайно много", но ровно в 2 раза
> больше, чем нужно - это точно :)

не ровно в 2 раза.

Если 10-12, 16-18 то между ними будет пустота,
а если 10-12, 12-18, то пустоты не будет

> Johnmen © (21.09.06 16:12) [25]
> Только почему-то я думаю, что будут проблемы. И всплывут они не сразу...
> Не пытай меня конкретикой, просто попомни...:)

Извини, не сдержался насчет "не пытай". В конце концов, мы сюда заходим не только для досужего трепа или выпендра, а еще и для обмена знаниями.
Я, конечно, понимаю, что не принято ставить составной частью ПК поле типа timestamp. И в серьезных системах я бы так делать и не стал. Но если отбросить условности, изъянов и скрытых камней я не обнаружил. А что ты обнаружил? Проблему 2099 года? :)

Непересекающиеся периоды в БД. Найти похожие ветки