|
|
|
Вычисляемое поле (разность дат)
|
|||
|---|---|---|---|
|
#18+
есть табица Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. из нее нужно выбрать phone_num, zone_id и время разговора, т.е. разность call_end и call_beg Заранее благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2006, 17:56 |
|
||
|
Вычисляемое поле (разность дат)
|
|||
|---|---|---|---|
|
#18+
1. Читай книги по SQL... 2. Чем не устраивают Код: plaintext 1. Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2006, 19:55 |
|
||
|
Вычисляемое поле (разность дат)
|
|||
|---|---|---|---|
|
#18+
АнатоЛой спасибо за помощь, но у меня тут еще сложность (что-то с датавременем не получается работать) нужно вернуть в результирующую выборку phone_num, zone_id, время в секундах с 8:00 до 23:00, время в секундах с 23:00 до 8:00. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2006, 14:23 |
|
||
|
Вычисляемое поле (разность дат)
|
|||
|---|---|---|---|
|
#18+
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. 1) Составить перечень вариантов, каким образом могут пересекаться интервалы разговоров с указанными интервалами учёта 8-23 и 23-8. Например, уточнить возможность вариантов, когда разговор может длиться с 7:00 до 23:30 или даже больше суток. 2) для каждого из вариантов написать свой запросИК :) 3) после этого думать об объединении полученных запросов в меньшее количество запросов (например, в 1 или в ХП)... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2006, 16:35 |
|
||
|
Вычисляемое поле (разность дат)
|
|||
|---|---|---|---|
|
#18+
В фразе АнатоЛой Для решения поставленной задачи подразумевалась, естественно, вот эта задача: Trorнужно вернуть в результирующую выборку phone_num, zone_id, время в секундах с 8:00 до 23:00, время в секундах с 23:00 до 8:00. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2006, 16:37 |
|
||
|
Вычисляемое поле (разность дат)
|
|||
|---|---|---|---|
|
#18+
АнатоЛой очень вам признателен за помощь не думайте что я халявщик и пришел просить готовое решение. дело в том что я пока только осваиваю Informix, а в имеющейся литературе я не нашел нужной информации. так что по поводу медвежьей улсуги можете не беспокоиться ;) у меня еще один вопросик вот пример тестового запроса который я сваял: Код: plaintext 1. 2. 3. он возвращает время разговора в минутах и секундах например "01:25" как теперь превратить это в 85 секунд пробовал использовать UNITS, но Informix ругается ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2006, 17:56 |
|
||
|
Вычисляемое поле (разность дат)
|
|||
|---|---|---|---|
|
#18+
Спасибо :) 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2006, 19:46 |
|
||
|
Вычисляемое поле (разность дат)
|
|||
|---|---|---|---|
|
#18+
спасибо за процедурку ;) RETURN (v_interval || '') + 0; -- пользуемся чуть-ли не единственной возможностью -- преобразования INTERVAL - преобразования в строку -- (ну а потом уже в INT) надеюсь, мое занудство вас еще не достало. по поводу преобразования можно поподробней ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 11:48 |
|
||
|
Вычисляемое поле (разность дат)
|
|||
|---|---|---|---|
|
#18+
Trorспасибо за процедурку ;) надеюсь, мое занудство вас еще не достало. по поводу преобразования можно поподробней Пожалуйста. Нет, не достало :) Но чувствуется, что Informix в твоей практике - первая тяжеловесная СУБД (а может задача с SQL первая тяжеловесная :). Код: plaintext 1) Выражение Код: plaintext 2) Код: plaintext Обидно только, что приходится пользоваться НЕЯВНЫМ преобразованием типов. Кстати, всё описанное я писал на IDS 7.31. Если у тебя более высокая версия - расскажи, как работает - тоже будет интересно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 14:02 |
|
||
|
Вычисляемое поле (разность дат)
|
|||
|---|---|---|---|
|
#18+
Доброго всем дня :) АнатоЛой я работаю в IDS 9.21 С3 в нем вроде есть оператор для явного приведения CAST, но я пока за него не брался. процедура работает замечательно. А с СУБД я столкнулся буквально 1,5 месяца назад, поэтому и знаний то у меня особо и нет, но я упорный :) кстати, приведенный тобой примерчик не работает на ночных звонках, поэтому я его немного переделал АнатоЛой Код: plaintext 1. 2. 3. 4. 5. 6. вот что получилось у меня в итоге. жду комментариев со стороны спецов ;) Код: 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. Заранее благодарен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 14:56 |
|
||
|
Вычисляемое поле (разность дат)
|
|||
|---|---|---|---|
|
#18+
Мысли вслух: 1) Примерчик, в отличие от РАБОТАВШЕЙ ХП, я не проверял, естественно :) 2) О вкусах не спорят, но я предпочитаю использовать не Код: plaintext Код: plaintext 3) Последнее время предпочитаю не возвращать большой объём строк ХП, а заполнять этими строками временную таблицу без логирования - мало кому и как с этими строками работать: можно и индекс построить, и отобрать потом нужные, ... 4) CAST не помешало бы помучить - его отсутствие в 7.31 как раз меня и огорчало :( :) Вопросы: 1) А зачем использовать транзакцию в данном случае Код: plaintext 1. 2. 2) Может ли звонок длится больше 9 или 15 часов? Если да, то, например, если он начнётся в 22:30 (дневное) и закончится в 8:30 (дневное), мы на самом деле имеем 32400 (9*60*60) ночных секунд и 3600 (1*60*60) дневных :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 17:12 |
|
||
|
Вычисляемое поле (разность дат)
|
|||
|---|---|---|---|
|
#18+
2) О вкусах не спорят, но я предпочитаю использовать не Код: plaintext а Код: plaintext - мне кажется так лаконичнее, удобнее (привычнее, в конце-концов :) теперь, когда вы показали альтернативу, мне тоже так кажется :) 3) Последнее время предпочитаю не возвращать большой объём строк ХП, а заполнять этими строками временную таблицу без логирования - мало кому и как с этими строками работать: можно и индекс построить, и отобрать потом нужные, ... вот-вот, вы предугадали мой следующий вопрос: как запихнуть всю эту кашу во временную таблицу? потом снова придется делать выборку из этой временной таблицы? а по поводу большого кол-ва строк, так это всего лишь первоначальный вариант, сейчас добавляю условия для отбора по конкретному клиенту и интервалу дат. 1) А зачем использовать транзакцию в данном случае Код: plaintext 1. 2. 3. я же говорю, что начал заниматься базами данных недавно, поэтому много чего еще не знаю. мне сказали, что так правильно, ну я и согласился по неопытности. а в каких случаях правильнее применять это? 2) Может ли звонок длится больше 9 или 15 часов? Если да, то, например, если он начнётся в 22:30 (дневное) и закончится в 8:30 (дневное), мы на самом деле имеем 32400 (9*60*60) ночных секунд и 3600 (1*60*60) дневных :) нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 17:37 |
|
||
|
Вычисляемое поле (разность дат)
|
|||
|---|---|---|---|
|
#18+
Похоже, что это учебное задание. Но если бы строилась промышленная система, я бы обязательно вот что сказал бы: Можно подумать о хранении числа ночных и дневных секунд в базе данных. Этот процесс называется денормализацией структуры БД. Его можно использовать в том случае, если у вас столбцы с датой начала и конца разговора обновляются намного реже (я вообще не представляю ситуацию, когда следует обновлять даты начала и конца разговора), чем рассчитывается число секунд разговора. Если у вас число тарифов изменяться не будет, можете добавить необходимое число столбцов прямо в эту таблицу, но лучше добавить дочернюю таблицу: 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. Я бы этот момент учитывать не стал бы:-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 11:39 |
|
||
|
Вычисляемое поле (разность дат)
|
|||
|---|---|---|---|
|
#18+
Tror как запихнуть всю эту кашу во временную таблицу? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. потом снова придется делать выборку из этой временной таблицы? Естественно :) Смотри на временную таблицу, как на кэш, из которого можно эффективнее получать даные. Например: 1) не просто последовательно, как ты это делаешь в ХП, а с группировками, используя индексы 2) неоднократно - один раз подготовив эти данные, ты можешь по ним сделать несколько запросов - отчётов Tror я же говорю, что начал заниматься базами данных недавно, поэтому много чего еще не знаю. мне сказали, что так правильно, ну я и согласился по неопытности. а в каких случаях правильнее применять это? Все мы чего-то не знаем... Я например, всегда считал, что транзакция необходима, чтобы сохранить логичную целостность НЕСКОЛЬКИХ ИЗМЕНЕНИЙ в БД - и либо согласиться со ВСЕМ ПАКЕТОМ изменений, либо ПОЛНОСТЬЮ отказаться от них... В твоей ХП ИЗМЕНЕНИЙ БД я не увидел... И даже если ты будешь пользоваться временной таблицей: 1) я предлагал использовать не логируемую - на неё не распространяется действие транзакций - но именно поэтому данные в неё будут быстрее записываться 2) нужно подумать - нужна ли тебе здесь транзакция (есть ли неободимость откатить паровоз вставок в эту временную таблицу - или тебе будет достаточно признак ошибки, уже предусмотрительно возвращаемый твоей процедурой...) zenk Можно подумать о хранении числа ночных и дневных секунд в базе данных. Этот процесс называется денормализацией структуры БД. Его можно использовать в том случае, если у вас столбцы с датой начала и конца разговора обновляются намного реже (я вообще не представляю ситуацию, когда следует обновлять даты начала и конца разговора), чем рассчитывается число секунд разговора. Полностью согласен. Можно добавить, что эти поля можно заполнять: 1) клиентом - но неудобно менять тарифы 2) триггером - удобнее, но 2.1. если ДАННЫЕ для расчёту тарифа будут прописаны в самом триггере, то при смене тарифа потребуется перерыв в работе пользователей 2.2. если ДАННЫЕ и логику хранить в таблице и триггером получать - то может оказаться время записи информации о звонке критично увеличится... 3) просто ХП тарификации звонков, которую запускать либо с какой-то регулярностью, либо перед ПОЛУЧЕНИЕМ этих данных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 15:00 |
|
||
|
|

start [/forum/topic.php?fid=44&msg=33659232&tid=1608700]: |
0ms |
get settings: |
7ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
40ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
| others: | 215ms |
| total: | 369ms |

| 0 / 0 |
