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

Вниз

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

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



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

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

Наверх









Память: 0.86 MB
Время: 0.031 c
3-21941
jin
2001-11-30 14:56
2002.01.08
Помогите пожалуйста создать процедуру IB SQL из приложения


1-22256
ходячий вопросник
2001-12-15 08:50
2002.01.08
Чтение значений из ini файла


3-21992
dlK
2001-12-06 15:21
2002.01.08
Как не дать программулине


6-22310
SERGX
2001-10-13 23:48
2002.01.08
ХЕЛП!! Как создать прогу для отсылки файла или текста по почте


14-22386
Дремучий
2001-11-08 21:13
2002.01.08
Интересно? Насколько?





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
Английский Французский Немецкий Итальянский Португальский Русский Испанский