ホーム
Top.Mail.Ru Yandeks.Metrika
フォーラム: "Bases";
現在のアーカイブ: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]

>巣
Ну да, в принципе идея ясна. Но это софтверный способ решения. Т.е. грубо говоря, перед тем, как я хочу что-то записать я делаю:
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 全枝

フォーラム: "Bases";
現在のアーカイブ:2002.01.08;
ダウンロード:[xml.tar.bz2];

2階









メモリ:0.86 MB
時間:0.038 c
14-22402
より暗い
2001-11-08 12:26
2002.01.08
ニックネームを持つ男を探しています


7-22441
ユリシーズ
2001-09-19 20:31
2002.01.08
Delphi 5 EntはWin2k Proの下で通常インストールされていません


14-22395
エイリアン
2001-11-07 01:15
2002.01.08
混乱は順序とどう違うのですか?


7-22448
スタニスラス
2001-09-11 15:24
2002.01.08
ディスケット上のデータ


1-22180
ネイサン
2001-12-21 11:07
2002.01.08
問題!





アフリカーンス語 アルバニア語 Arabic アルメニア語 アゼルバイジャン語 バスク ベラルーシ Bulgarian カタロニア語 中国語(簡体字) 中国語(繁体字) クロアチア チェコ語 デンマーク語 Dutch 英語 エストニア語 タガログ語 Finnish フランス語
ガリシア語 ジョージアン ドイツ語 ギリシャ語 ハイチ語 ヘブライ語 ヒンディー語 ハンガリー語 アイスランド語 Indonesian アイリッシュ イタリア語 日本語 Korean ラトビア語 リトアニア マケドニア語 Malay マルタ語 Norwegian
ペルシア語 ポリッシュ ポルトガル語 ルーマニア Russian セルビア Slovak スロベニア語 スペイン語 スワヒリ語 Swedish Thai トルコ語 ウクライナ語 ウルドゥー語 ベトナム語 ウェールズ語 イディッシュ語 ベンガル語 ボスニア語
セブアノ語 エスペラント グジャラート語 ハウサ語 モン族 イボ ジャワ語 カンナダ語 クメール語 ラオ語 ラテン マオリ語 マラーティー語 モンゴル語 ネパール語 パンジャブ語 ソマリ タミル語 テルグ語 ヨルバ語
ズールー語
Английский Французский Немецкий Итальянский ポルトガル語 Русский Испанский