ВСЕМ ПРИВЕТ! Делаю некий журнал. Откуда задача....

← →
@andrew (2001-12-04 11:38) [0]

...необходимо сделать проверку на уникальность введенной даты. Чтобы на одно и тоже время не приходилось два события. Не подскажите, как это проверку вбить конструктором таблицы или запросом перед строкой "insert into....."? Спасибо!

← →
Val (2001-12-04 13:11) [1]

нужна не проверка, а уникальный индекс, в который будет входить это поле даты

← →
@andrew (2001-12-04 13:58) [2]

А это как: "в который будет входить поле даты"? Имеется ввиду, что поле "дата" уникально? Если это имеется ввиду, то это не совсем годится, т.к. на самом деле, интересует чтобы временные интервалы события не пересекались. Напр. одно событие с 5 до 8 утра. Другое - с 6 до 7. Если делать проверку по уникальности индекса, то SQL позволит сделать запись, а не должен.

← →
@andrew (2001-12-04 14:05) [3]

На самом деле, можно придумать несколько алгаритмов решения моей задачи. Самый элементарный, который у меня в голове крутится, а именно: сначала возвращать все значения, потом перебирать их, смотреть... и т.д. - очень длинный и тормозной. Может просто кто-нибудь сталкивался и знает какое-нибудь готовое решение моего вопроса: быстрое и простое и все-таки, желательно, не на уровне софта, а на уровне SQL или запроса SQL, т.к. в варианте решения вопроса на уровне софта при работе сразу большого кол-ва пользователей задержка во времени "select * ...; проверка.....; если все в порядке-insert что-то...." может оказаться роковой.

Еще раз заранее Спасибо!

← →
Mick (2001-12-04 14:07) [4]

Вообще нормальные журналы пишутся последовательно. Дата вставляется не клиентом, а сервером. Если некий процесс начался в 5, а кончился в 8, то в журнале будет 1 запись о начале(5 утра), одна запись об окончании (8 утра) и туча записей между ними, которые расскажут что в это время было.

← →
Nest (2001-12-04 14:14) [5]

Да, вчера у меня тоже такой вопрос встал.
Но я пока отложил его решение - есть поважнее дела.
А вообще я думаю, у тебя период должен характеризоваться 2мя параметрами-
дата_время_начала и дата_время_конца.
Так вот если в каждый момент времени может происходить только олно событие, то при вводе нужно проверять,чтобы :
[1.дата_время_начала<дата_время_конца]
2.Несуществует записи,у которой дата_время_конца пусто либо больше вводимого дата_время_начала.

Наверное эти мысли надо до ума довести - небыло времени.Пока только смутная идея.
Покатит?

← →
@andrew (2001-12-04 14:17) [6]

>Mick
Не совсем то.
Речь идет не о журнале в компьютерном смысле слова, а о журнале, как об органайзере, ежедневнике, в который можно записать некие планы на будующее время.

← →
@andrew (2001-12-04 14:24) [7]

>Nest
Ну да, в принципе идея ясна. Но это софтверный способ решения. Т.е. грубо говоря, перед тем, как я хочу что-то записать я делаю:
1. Возвращаю все записи, сортируя их по дате_времени.
2. Становлюсь на последнюю строку (Query1.Last)
3. Если время начала того, что я хочу вставить >= время конца последней записи, то можно сделать Insert.
А можно ли тоже самое, только не софтом, а запросом?

Я просто боюсь, что при одновременной работе нескольких людей можно облажаться.

← →
Nest (2001-12-04 14:36) [8]

А что так не покатит?
1.Query1: Select max(ДВК)
2.If query1.fields[0].asdatetime>ДВН_вводимое then abort

Чтобы сделать и проверку и вставку одним запросом, надо, IMHO, нехило изъ№%@ться. А парой - несложно.

← →
Nest (2001-12-04 14:38) [9]

Может и можно - просто посидеть подумать над элементарной логикой,и как представить это в WHERE запроса.
Я идею дал - дальше попытайся подумать. У меня просто реально времени нет.

← →
Mick (2001-12-04 14:39) [10]

Можно пойти по пути денормализации таблицы журнала.
Структура:
1.Поле ключа (любой искусственный Primary Key)
2.Дата
3 Поля часов (по количеству часов в сутках)

Далее:
Клиент проверяет непрерывность вставляемого интервала (легко)
Триггер в таблице проверяет есть ли NOT NULL значения в одноименных полях в записях для такой же даты.
Если есть, значит поймали перекрытие событий, если нет - все нормально.

← →
Sam (2001-12-04 19:27) [11]

А как насчет триггеров?

← →
kaif (2001-12-04 20:17) [12]

Я пару лет назад решал такую точно задачу для организации приема у врачей. Делал на InterBase. Алгоритм совсем нетривиальный получился. Для того, чтобы это работало быстро, разумеется, нужны индексы. Пришлось создавать промежутки, как отдельные записи, потребовались хранимые процедуры "дробления" промежутков и "склеивания". Вначале создаются "промежутки свободного времени", затем они дробятся, по мере того, как какое-то время занимается. Соответственно, их количество постепенно возрастает. Конкретные дела привязываются к суррогатному уникальному индексу этих промежутков. Работало быстро и непротиворечиво при одновременном доступе ряда пользователей. Я тогда много думал и пробовал разных вариантов. Без превращения отдельных промежутков в объекты, которые бы создавались, удалялись и использовались - иного хорошего решения не нашел.

ВСЕМ ПРИВЕТ! Делаю некий журнал. Откуда задача.... Найти похожие ветки