Пойти чтоли потрясти генерального по поводу новой железки для себя любимого... хоть какое-то развлечение с утра)

Хорошее развлечение

я вот думаю что мне будет проще, научить астер приводить cid и did к единому виду или триггеры mysql изучить before insert

Постгрес выучить и в нем тригерные функции))

не хочу ( чем он лучше?

Мускуль с триггером это как корова с седлом

пруфы в студию

Ну ты ж не спрашиваешь чем к поимеру оракл лучше мускул))) принимаешь просто на веру

да, мне тоже хотелось бы знать

ну фиг знает насчет "лучше", если платный саппорт mysql проплатить

хотя я пожалуй помолчу, я сегодня уже позорился на эту тему

Хорошо. Тогда попробуйте мне объяснить как в триггере мускуля перед вставкой обработать поле и в зависимости от вычислений по заданому условию из второй таблицы сделать вставку результата в третью таблицу?

Как бы смесь из select , if и insert)

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

что есть вторая таблица?

Давайте условие задачи нормально Есть таблица 1, таблица 2 и тд

Во , тогда просто посмотри по диагонали триггеры в мускуле и постгресе. И пусть твой незамутненный мозг сравнит)

надо сделать так то и так то

Я работаю и с тем и с тем

не наблюдаю проблем с триггерами ни там ни там

Замутнение мозга - это плохая вещь. Избавляйся от этого. Работать да и жить будет легче

И скажите, что удобней тогда для построения логики)?

AFTER INSERT OR UPDATE OR DELETE

вот за это можно перейти на postgre пожалуй

у мускуля, как я понял, так нельзя

можно

Да, можно

у него так же триггеры навешиваются на постобработку и на предобработку

Поссмотри на тригерную функцию в постгре

и можно один триггер на несколько вариантов срабатывания?

с точки зрения умных людей номера приводить к единому виду логичнее в самом CDR(ну вот к примеру триггером перед инсертом) или в диалплане?

Нет тут правилнього ответа

Все зависит от инфраструктуры

она очень проста, 4 оператора, три транка, 1 инстанс

если БД сильно нагружена другими сервисами то можно сначала обатотать а потом уже сделать вставку не нагружая ьд триггерами

нет, туда только CDR пишется

если же бд служит исключительно для сервиса телефонии то можно и триггером сделать чтобы с телефонии снять эту функцию

получается что всё-таки триггер

ага

ну в данном случае видимо да

Я считаю, что не правильно перекладывать задачу телефонии на СУБД. Таким образом(триггерамми) и duration можно считать и биллинг.....

перестаньте запутывать енота

конечно можно

И во многих случаях даже нужно

это не задача телефонии

задача телефонии сгенирировать данные

задача биллинг подсистемы посчитать биллин

задача сервиса, котороый ответсвеннен за вывод данных пользовалтелю (через веб) привести эти данные к правильному виду

телефония в данном случае может эти данные опубликовать в максимально сылом и удобном для обработки виде

тут еще нужно спросить себя вот о чем

Если в один прекрасный момент по какой либо причине поменяются требования к отображению cid и did - удобно ли это будет переделать переписав триггер?

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

ТУт вопрос в архитектуре

Способов реализации куча

и правильного нет

у меня огроменный SQL-запрос, он основан на том что данные в таблице в одном виде лежат

есть тот, который будет удобен в перспективе и будет удобно встроен в сервис

ну вот то что SQL запрос сам по себе огроменный уже сигнал к тому что что то в архитектуре не так

ну почему же, просто фильтровать лучше в запросе

он не очень изящен, но работу свою делает SELECT DISTINCT (caller_id_number) as not_answered_calls FROM cdr WHERE caller_id_number not in ( SELECT DISTINCT (caller_id_number) FROM cdr WHERE caller_id_number in ( SELECT DISTINCT (caller_id_number) FROM cdr WHERE destination_number in (79333239492,79333220372,79233555042) AND destination_number NOT in ('anonymous') AND caller_id_number NOT in ('anonymous') AND CHAR_LENGTH(caller_id_number) > 4 AND start_stamp > '2018-03-01' AND start_stamp < '2018-03-31' ORDER BY caller_id_number, start_stamp, hangup_cause ) AND destination_number in (79333239492,79333220372,79233555042) AND CHAR_LENGTH(caller_id_number) > 4 AND billsec > 5 AND start_stamp > '2018-03-01' AND start_stamp < '2018-03-31' ORDER BY caller_id_number, start_stamp, hangup_cause ) AND destination_number in (79333239492,79333220372,79233555042) AND CHAR_LENGTH(caller_id_number) > 4 AND start_stamp > '2018-03-01' AND start_stamp < '2018-03-31' AND billsec <= 5 ORDER BY caller_id_number, start_stamp, hangup_cause;

Я Вам приведу пример: Я работал с одним food-delivery сервисом У них крутится АТС которая сыплет в БД кучу информации о заказах Есть у них ПО которое из БД всю эту кучу доставало Вот примерно таким запросом как это делаете вы

так вот снаала появились long queries

так как данные доставвались из журнала

потом база начала сыпаться периодически

это при том что innoDB и особо никаких блокировок там не было

просто запрос собирал из 3 таблиц данные котороые были очень контексто зависимы

Здесь только 1 таблица, хотя может быть в будущем добавятся ещё 2

вопрос решился переписыанием механизма котроый доставал данные из журнала простым запросом

соответсевнно данные за полгода доставались вместо 150 секунд за 12

так вот я это все к чему

Мб в вашем случае имеет смысл сначала подумать над архитектурой и немного ее поменять чтобы потом не отгрести чистюлей за падение базы в продакшн и не дискредитировать себя в глазах руководства?

эх, звучит так будто я работаю в серьезной конторе

А какая разница где вы работаете?

Работа должна выполняться так чтобы ей можно было гордиться

это вы сегодня тут работаете

завтра найдете другую работу

я про дискредитацию

и вас спросят - а что вы делали на предыдущей

а вы скажете - херню какую то

а мне есть что ответить))

Я к тому что это ж все опыт

конечно его можно взять и просрать)))

но я бы рекомендовал вкладываться в себя

я вот свято уверен что лучше фильтровать в SQL запросе

понимаете, чтобы что то фильтровать надо данные для фильтра сначала сложить

чтобы потом фильтром не убить сервер

куда сложить?

фильтрация же это только следствие

В базу данных конечно

мы же об этом гооврим

так сложено уже, я немного не успеваю за нитью ваших размышлений

надо отвалидировать и фильтр будет воркать файн

не хочу ( чем он лучше?

Другой сорт гавна (с)

Другой сорт гавна (с)

там "о"

нет, туда только CDR пишется

А вот реляционная бд только для сдр - так себе

там "о"

В курсе

А вот реляционная бд только для сдр - так себе

по планам там ещё на каждый номер телефона будет небольшое досье в двух таблицах. первая - парсинг этого сайта phonenum.info/phone/ вторая - данные от наших кадровиков (отметки\заметки)