Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Informix [игнор отключен] [закрыт для гостей] / Вычисляемое поле (разность дат) / 14 сообщений из 14, страница 1 из 1
07.04.2006, 17:56
    #33653072
Tror
Tror
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вычисляемое поле (разность дат)
есть табица
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
create table 'informix'.calls (
    call_id SERIAL not null,
    phone_num CHAR( 9 ) not null,
    zone_id CHAR( 10 ) not null,
    call_beg DATETIME YEAR TO SECOND not null,
    call_end DATETIME YEAR TO SECOND not null,
    kagent_phone_num NVARCHAR( 25 ) not null
)

из нее нужно выбрать phone_num, zone_id и время разговора,
т.е. разность call_end и call_beg
Заранее благодарен.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.04.2006, 19:55
    #33653285
АнатоЛой
АнатоЛой
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вычисляемое поле (разность дат)
1. Читай книги по SQL...
2. Чем не устраивают
Код: plaintext
1.
SELECT phone_num, zone_id, (call_end - call_beg) AS talk_time
  FROM calls;
или
Код: plaintext
1.
2.
3.
SELECT phone_num, zone_id, SUM(call_end - call_beg) AS talk_time
  FROM calls;
  GROUP BY  1 ,  2 ;
?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2006, 14:23
    #33655964
Tror
Tror
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вычисляемое поле (разность дат)
АнатоЛой
спасибо за помощь, но у меня тут еще сложность
(что-то с датавременем не получается работать)
нужно вернуть в результирующую выборку
phone_num, zone_id, время в секундах с 8:00 до 23:00, время в секундах
с 23:00 до 8:00.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2006, 16:35
    #33656474
АнатоЛой
АнатоЛой
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вычисляемое поле (разность дат)
1. Читай книги по SQL... В том числе по синтаксису Informix SQL. Многие не читают последовательно :) - берут pdf файл и пользуются содержанием, алфавитным указателем и просто поиском
2. Если это вопрос по работе или учёбе - смотри пункт 1. Если это вопрос из тестового задания по ПРИЁМУ на работу, и время есть - см.п.1.
3. Если времени нет - надеюсь моя помощь не будет медвежьей услугой :( - проще отказаться от ждущей тебя работы, пока не подымешь свой уровень знаний и умений...
4. Если в даной задаче проблема только с "(что-то с датавременем не получается работать)" то вот пример работы с "датавременем" при решении более простой задачи:
"В разрезе номеров и зон получить длительность звонков, которые НАЧАЛИСЬ!!! с 8:00 (включительно) до 23:00 (НЕ включительно!!!) , и длительность звонков, которые начались с 23:00 (включительно) до 8:00 (НЕ включительно!!!)".
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
SELECT phone_num, zone_id, 
  SUM(
    CASE
      WHEN
        EXTEND(call_beg, HOUR TO SECOND) 
          BETWEEN DATETIME( 8 : 00 : 00 ) HOUR TO SECOND
                 AND DATETIME( 22 : 59 : 59 ) HOUR TO SECOND
        THEN call_end - call_beg
      ELSE  0 
    END
  ) AS business_time
,
  SUM(
    CASE
      WHEN
        EXTEND(call_beg, HOUR TO SECOND)
          BETWEEN DATETIME( 23 : 00 : 00 ) HOUR TO SECOND
                 AND DATETIME( 7 : 59 : 59 ) HOUR TO SECOND
        THEN call_end - call_beg
      ELSE  0 
    END
  ) AS not_business_time
  FROM calls
  GROUP BY  1 ,  2 ;
Для решения поставленной задачи предлагаю:
1) Составить перечень вариантов, каким образом могут пересекаться интервалы разговоров с указанными интервалами учёта 8-23 и 23-8. Например, уточнить возможность вариантов, когда разговор может длиться с 7:00 до 23:30 или даже больше суток.
2) для каждого из вариантов написать свой запросИК :)
3) после этого думать об объединении полученных запросов в меньшее количество запросов (например, в 1 или в ХП)...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2006, 16:37
    #33656486
АнатоЛой
АнатоЛой
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вычисляемое поле (разность дат)
В фразе
АнатоЛой
Для решения поставленной задачи
подразумевалась, естественно, вот эта задача:
Trorнужно вернуть в результирующую выборку
phone_num, zone_id, время в секундах с 8:00 до 23:00, время в секундах
с 23:00 до 8:00.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2006, 17:56
    #33656719
Tror
Tror
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вычисляемое поле (разность дат)
АнатоЛой
очень вам признателен за помощь
не думайте что я халявщик и пришел просить готовое решение.
дело в том что я пока только осваиваю Informix, а в имеющейся
литературе я не нашел нужной информации. так что по поводу
медвежьей улсуги можете не беспокоиться ;)

у меня еще один вопросик
вот пример тестового запроса который я сваял:

Код: plaintext
1.
2.
3.
SELECT EXTEND(call_end, MINUTE TO SECOND) - EXTEND(call_beg, MINUTE TO SECOND) FROM calls
WHERE (EXTEND(call_beg, HOUR TO SECOND) < EXTEND('07:59:59', HOUR TO SECOND) OR
      EXTEND(call_beg, HOUR TO SECOND) > EXTEND('23:00:00', HOUR TO SECOND))

он возвращает время разговора в минутах и секундах
например "01:25" как теперь превратить это в 85 секунд
пробовал использовать UNITS, но Informix ругается
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2006, 19:46
    #33656940
АнатоЛой
АнатоЛой
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вычисляемое поле (разность дат)
Спасибо :)
1. Контрольно напоминаю, что EXTEND(call_end, MINUTE TO SECOND) не ПЕРЕВЕДЁТ в минуті с секундами, а ВЫРЕЖЕТ из датывремени МИНУТЫ И СЕКУНДЫ, игнорируя всё остальное. Т.е. EXTEND(call_end, MINUTE TO SECOND) - EXTEND(call_beg, MINUTE TO SECOND) может быть и отрицательным, если разговор начался в 9:50 а закончился в 10:01.
2. Со знаками "больше" и "меньше" - обращай внимание на граничные значения - может всё таки не "< EXTEND('07:59:59')", а "<= EXTEND('07:59:59')", либо "< EXTEND('08:00:00')"?!
3. С разницей в секундах меня тоже в своё время интересовал эта задача и я сделал следующее решение (здесь следует реверанс Василию Шульженко за DBATools и Larry Kemmerling за ХП datetime2utc :) ):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
CREATE PROCEDURE interval_in_sec(
    p_dt1 DATETIME YEAR TO SECOND
  , p_dt2 DATETIME YEAR TO SECOND
) RETURNING
  INT;

  DEFINE v_interval INTERVAL SECOND( 9 ) TO SECOND; 
  -- при операциях заставить ПЕРЕВОДИТЬ единицы исключительно в секунды

  LET v_interval = (p_dt2 - p_dt1); -- ПЕРЕВОДИМ в интервал В СЕКУНДАХ
  RETURN (v_interval || '') +  0 ;
  -- пользуемся чуть-ли не единственной возможностью 
  -- преобразования INTERVAL - преобразования в строку
  -- (ну а потом уже в INT)

END PROCEDURE;
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
11.04.2006, 11:48
    #33657823
Tror
Tror
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вычисляемое поле (разность дат)
спасибо за процедурку ;)


RETURN (v_interval || '') + 0;
-- пользуемся чуть-ли не единственной возможностью
-- преобразования INTERVAL - преобразования в строку
-- (ну а потом уже в INT)

надеюсь, мое занудство вас еще не достало.
по поводу преобразования можно поподробней
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
11.04.2006, 14:02
    #33658362
АнатоЛой
АнатоЛой
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вычисляемое поле (разность дат)
Trorспасибо за процедурку ;)
надеюсь, мое занудство вас еще не достало.
по поводу преобразования можно поподробней
Пожалуйста.
Нет, не достало :) Но чувствуется, что Informix в твоей практике - первая тяжеловесная СУБД (а может задача с SQL первая тяжеловесная :).

Код: plaintext
RETURN (v_interval || '') +  0 ;
Здесь суть проста:
1) Выражение
Код: plaintext
v_interval || ''
за счёт склейки с пустой строкой преобразовывается в строку, в которой записана длительность интервала. Поскольку интервал v_interval измерятся только в секундах - в СТРОКЕ записано КОЛИЧЕСТВО СЕКУНД.
2)
Код: plaintext
+  0
преобразовывает тип выражения в число - количество секунд.

Обидно только, что приходится пользоваться НЕЯВНЫМ преобразованием типов.
Кстати, всё описанное я писал на IDS 7.31. Если у тебя более высокая версия - расскажи, как работает - тоже будет интересно :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
11.04.2006, 14:56
    #33658536
Tror
Tror
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вычисляемое поле (разность дат)
Доброго всем дня :)

АнатоЛой
я работаю в IDS 9.21 С3
в нем вроде есть оператор для явного приведения CAST, но я пока за него
не брался. процедура работает замечательно. А с СУБД я
столкнулся буквально 1,5 месяца назад, поэтому и знаний то у меня
особо и нет, но я упорный :)

кстати, приведенный тобой примерчик не работает на ночных звонках,
поэтому я его немного переделал
АнатоЛой
Код: plaintext
1.
2.
3.
4.
5.
6.
  SUM(
    CASE
      WHEN
        EXTEND(call_beg, HOUR TO SECOND)
          BETWEEN DATETIME( 23 : 00 : 00 ) HOUR TO SECOND
                 AND DATETIME( 7 : 59 : 59 ) HOUR TO SECOND
        THEN call_end - call_beg


вот что получилось у меня в итоге.
жду комментариев со стороны спецов ;)

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
CREATE FUNCTION "informix".process_calls()
RETURNING CHAR( 9 ), CHAR( 10 ), INT, INT, INT

DEFINE _sqlcode, _ret INT;
DEFINE _phone_num CHAR( 9 );
DEFINE _zone_id CHAR( 10 );
DEFINE _b_time INT;
DEFINE _not_b_time INT;
DEFINE _beg_date, _end_date, _tmp_date DATETIME YEAR TO SECOND;
ON EXCEPTION SET _sqlcode
ROLLBACK WORK;
RETURN '', '',  0 ,  0 , _sqlcode;
END EXCEPTION;
SET LOCK MODE TO WAIT  5 ;

    LET _ret =  0 ;
    BEGIN WORK; 
    
          FOREACH
                 SELECT phone_num, zone_id, call_beg, call_end
                 INTO _phone_num, _zone_id, _beg_date, _end_date
                 FROM calls
                 
                 -- если разговор начался в ДНЕВНОЕ время, а закончился в НОЧНОЕ
                 IF ((EXTEND(_beg_date, HOUR TO SECOND)
                    BETWEEN DATETIME( 8 : 00 : 00 ) HOUR TO SECOND
                            AND
                            DATETIME( 22 : 59 : 59 ) HOUR TO SECOND))
                    AND
                    ((EXTEND(_end_date, HOUR TO SECOND)
                    BETWEEN DATETIME( 23 : 00 : 00 ) HOUR TO SECOND
                            AND
                            DATETIME( 7 : 59 : 59 ) HOUR TO SECOND)
                    ) THEN
                    LET _tmp_date = EXTEND(_beg_date, YEAR TO DAY) + EXTEND('22:59:59', HOUR TO SECOND);
                    CALL interval_in_sec(_beg_date, _tmp_date) RETURNING _b_time;
                    CALL interval_in_sec(_tmp_date, _end_date) RETURNING _not_b_time;
                    
                    RETURN _phone_num, _zone_id, _b_time, _not_b_time,  0  WITH RESUME;
                    
                 -- если разговор начался в ДНЕВНОЕ время и закончился также в ДНЕВНОЕ   
                 ELIF ((EXTEND(_beg_date, HOUR TO SECOND)
                      BETWEEN DATETIME( 8 : 00 : 00 ) HOUR TO SECOND
                              AND
                              DATETIME( 22 : 59 : 59 ) HOUR TO SECOND))
                      AND
                      ((EXTEND(_end_date, HOUR TO SECOND)
                      BETWEEN DATETIME( 7 : 59 : 59 ) HOUR TO SECOND
                              AND
                              DATETIME( 23 : 00 : 00 ) HOUR TO SECOND)
                    ) THEN
                    CALL interval_in_sec(_beg_date, _end_date) RETURNING _b_time;
                    LET _not_b_time =  0 ;
                    
                    RETURN _phone_num, _zone_id, _b_time, _not_b_time,  0  WITH RESUME;
                    
                 -- если разговор начался в НОЧНОЕ время, а закончился в ДНЕВНОЕ   
                 ELIF ((EXTEND(_beg_date, HOUR TO SECOND)
                      BETWEEN DATETIME( 23 : 00 : 00 ) HOUR TO SECOND
                              AND
                              DATETIME( 00 : 00 : 00 ) HOUR TO SECOND)
                      OR (EXTEND(_beg_date, HOUR TO SECOND)
                      BETWEEN DATETIME( 00 : 00 : 01 ) HOUR TO SECOND
                              AND
                              DATETIME( 7 : 59 : 59 ) HOUR TO SECOND))
                      AND
                      ((EXTEND(_end_date, HOUR TO SECOND)
                      BETWEEN DATETIME( 8 : 00 : 00 ) HOUR TO SECOND
                              AND
                              DATETIME( 22 : 59 : 59 ) HOUR TO SECOND)
                    ) THEN
                    LET _tmp_date = EXTEND(_beg_date, YEAR TO DAY) + EXTEND('7:59:59', HOUR TO SECOND);
                    CALL interval_in_sec(_beg_date, _tmp_date) RETURNING _not_b_time;
                    CALL interval_in_sec(_tmp_date, _end_date) RETURNING _b_time;
                    
                    RETURN _phone_num, _zone_id, _b_time, _not_b_time,  0  WITH RESUME;
                    
                 -- если разговор начался в НОЧНОЕ время и закончился также в НОЧНОЕ   
                 ELIF ((EXTEND(_beg_date, HOUR TO SECOND)
                      BETWEEN DATETIME( 23 : 00 : 00 ) HOUR TO SECOND
                              AND
                              DATETIME( 00 : 00 : 00 ) HOUR TO SECOND)
                      OR (EXTEND(_beg_date, HOUR TO SECOND)
                      BETWEEN DATETIME( 00 : 00 : 01 ) HOUR TO SECOND
                              AND
                              DATETIME( 7 : 59 : 59 ) HOUR TO SECOND))
                      AND
                      ((EXTEND(_end_date, HOUR TO SECOND)
                      BETWEEN DATETIME( 23 : 00 : 00 ) HOUR TO SECOND
                              AND
                              DATETIME( 00 : 00 : 00 ) HOUR TO SECOND)
                      OR (EXTEND(_beg_date, HOUR TO SECOND)
                      BETWEEN DATETIME( 00 : 00 : 01 ) HOUR TO SECOND
                              AND
                              DATETIME( 7 : 59 : 59 ) HOUR TO SECOND)
                    ) THEN
                    CALL interval_in_sec(_beg_date, _end_date) RETURNING _not_b_time;
                    LET _b_time =  0 ;
                    
                    RETURN _phone_num, _zone_id, _b_time, _not_b_time,  0  WITH RESUME;
                 END IF;
          END FOREACH;
          
    COMMIT WORK;
    RETURN '', '',  0 ,  0 , _ret;

END FUNCTION;

Заранее благодарен
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
11.04.2006, 17:12
    #33659146
АнатоЛой
АнатоЛой
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вычисляемое поле (разность дат)
Мысли вслух:
1) Примерчик, в отличие от РАБОТАВШЕЙ ХП, я не проверял, естественно :)

2) О вкусах не спорят, но я предпочитаю использовать не
Код: plaintext
       CALL interval_in_sec(_beg_date, _tmp_date) RETURNING _b_time;
а
Код: plaintext
       LET _b_time = interval_in_sec(_beg_date, _tmp_date);
- мне кажется так лаконичнее, удобнее (привычнее, в конце-концов :)
3) Последнее время предпочитаю не возвращать большой объём строк ХП, а заполнять этими строками временную таблицу без логирования - мало кому и как с этими строками работать: можно и индекс построить, и отобрать потом нужные, ...

4) CAST не помешало бы помучить - его отсутствие в 7.31 как раз меня и огорчало :( :)

Вопросы:
1) А зачем использовать транзакцию в данном случае
Код: plaintext
1.
2.
BEGIN WORK;
...
COMMIT WORK;
?

2) Может ли звонок длится больше 9 или 15 часов? Если да, то, например, если он начнётся в 22:30 (дневное) и закончится в 8:30 (дневное), мы на самом деле имеем 32400 (9*60*60) ночных секунд и 3600 (1*60*60) дневных :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
11.04.2006, 17:37
    #33659232
Tror
Tror
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вычисляемое поле (разность дат)
2) О вкусах не спорят, но я предпочитаю использовать не

Код: plaintext
CALL interval_in_sec(_beg_date, _tmp_date) RETURNING _b_time;

а

Код: plaintext
LET _b_time = interval_in_sec(_beg_date, _tmp_date);

- мне кажется так лаконичнее, удобнее (привычнее, в конце-концов :)

теперь, когда вы показали альтернативу, мне тоже так кажется :)


3) Последнее время предпочитаю не возвращать большой объём строк ХП, а заполнять этими строками временную таблицу без логирования - мало кому и как с этими строками работать: можно и индекс построить, и отобрать потом нужные, ...

вот-вот, вы предугадали мой следующий вопрос:
как запихнуть всю эту кашу во временную таблицу?
потом снова придется делать выборку из этой временной таблицы?
а по поводу большого кол-ва строк,
так это всего лишь первоначальный вариант, сейчас добавляю
условия для отбора по конкретному клиенту и интервалу дат.

1) А зачем использовать транзакцию в данном случае
Код: plaintext
1.
2.
3.
BEGIN WORK;
...
COMMIT WORK;


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


2) Может ли звонок длится больше 9 или 15 часов? Если да, то, например, если он начнётся в 22:30 (дневное) и закончится в 8:30 (дневное), мы на самом деле имеем 32400 (9*60*60) ночных секунд и 3600 (1*60*60) дневных :)

нет
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.04.2006, 11:39
    #33660588
zenk
zenk
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вычисляемое поле (разность дат)
Похоже, что это учебное задание. Но если бы строилась промышленная система, я бы обязательно вот что сказал бы:

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

Если у вас число тарифов изменяться не будет, можете добавить необходимое число столбцов прямо в эту таблицу, но лучше добавить дочернюю таблицу:

create table 'informix'.calls_tarif (
id SERIAL,
call_id longint,
phone_num CHAR(9) not null,
zone_id CHAR(10) not null,
id_tarif SMALLINT NOT NULL,
time_tariff int,
kagent_phone_num NVARCHAR(25) not null

или такую:
create table 'informix'.calls_tarif (
id SERIAL,
call_id longint,
id_tarif SMALLINT NOT NULL,
time_tariff int).

Первая таблица денормализованная - такая структура позволит быстро обрабатывать запросы отчётного типа.

Да, не забудьте про переходы с летнего времени на зимнее и наоборот. Кроме того, иногда для корректировки календарного времени с астрономическим применяют прибавление/отнимание 1 секунды 31 декабря в 23:59.
Я бы этот момент учитывать не стал бы:-)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.04.2006, 15:00
    #33661524
АнатоЛой
АнатоЛой
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вычисляемое поле (разность дат)
Tror
как запихнуть всю эту кашу во временную таблицу?


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
  BEGIN
    ON EXCEPTION IN (- 206 ) -- table not in the database
    END EXCEPTION WITH RESUME;

    DROP TABLE tmpProcessCalls;
  END

  CREATE TEMP TABLE tmpProcessCalls(
    phone_num CHAR( 9 ), _zone_id CHAR( 10 ), _b_time INT, _not_b_time INT
  ) WITH NO LOG;

  FOREACH
     ...
     INSERT INTO tmpProcessCalls(...) VALUES (...);
  END FOREACH;
Tror
потом снова придется делать выборку из этой временной таблицы?


Естественно :)

Смотри на временную таблицу, как на кэш, из которого можно эффективнее получать даные. Например:
1) не просто последовательно, как ты это делаешь в ХП, а с группировками, используя индексы
2) неоднократно - один раз подготовив эти данные, ты можешь по ним сделать несколько запросов - отчётов

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

Все мы чего-то не знаем... Я например, всегда считал, что транзакция необходима, чтобы сохранить логичную целостность НЕСКОЛЬКИХ ИЗМЕНЕНИЙ в БД - и либо согласиться со ВСЕМ ПАКЕТОМ изменений, либо ПОЛНОСТЬЮ отказаться от них...
В твоей ХП ИЗМЕНЕНИЙ БД я не увидел... И даже если ты будешь пользоваться временной таблицей:
1) я предлагал использовать не логируемую - на неё не распространяется действие транзакций - но именно поэтому данные в неё будут быстрее записываться
2) нужно подумать - нужна ли тебе здесь транзакция (есть ли неободимость откатить паровоз вставок в эту временную таблицу - или тебе будет достаточно признак ошибки, уже предусмотрительно возвращаемый твоей процедурой...)

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

Полностью согласен. Можно добавить, что эти поля можно заполнять:
1) клиентом - но неудобно менять тарифы
2) триггером - удобнее, но
2.1. если ДАННЫЕ для расчёту тарифа будут прописаны в самом триггере, то при смене тарифа потребуется перерыв в работе пользователей
2.2. если ДАННЫЕ и логику хранить в таблице и триггером получать - то может оказаться время записи информации о звонке критично увеличится...
3) просто ХП тарификации звонков, которую запускать либо с какой-то регулярностью, либо перед ПОЛУЧЕНИЕМ этих данных
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Informix [игнор отключен] [закрыт для гостей] / Вычисляемое поле (разность дат) / 14 сообщений из 14, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 347ms
Закрыть
start [/forum/topic.php?fid=44&mobile=1&tid=1608700]:
 0ms
get settings:
 5ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 70ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 44ms
get tp. blocked users:
 1ms
others: 194ms
total:  347ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]