О производительности postgres vs application

[DAN]

Старожил PHPClub
О производительности postgres vs application

Бодрого времени суток!
Задумался тут вот над каким вопросом.
Имеется некоторый лог телефонного разговора, который надо отбилловать в обе стороны и загрузить в БД.
Логи могут приходить из различных источников (соответственно и собираться различными приложениями). Так вот, что будет быстрее/удобнее - билловать лог в приложении и кидать в БД готовые данные, либо отдавать "сырой" лог в БД и в ней уже (триггеры/процедуры) производить с этим логом манипуляции?

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

С другой стороны при определенном числе запросов (инсерты логов + работа с полученной информацией) не загнется ли постргя как та корова?

Мне лично ближе "к телу" зашить бизнес-логику в процедуры БД. В связи с этим ковыряю в сторону оптимизации постгри. Индексы там всякие, нормальные формы и т.д.

Уважаемый all, а что вы думаете по этому поводу?
 

trigger

Guest
Мне "ближе к телу" базой хранить, а не обрабатывать, а обрабатывать тем, что для этого и было создано. На вкус и цвет... (или на мудрость прожектера)
Может, лучше обрабатывать тем, что собираешься масштабировать?
 

svetasmirnova

маленький монстрик
[DAN]
Я думаю, что так и надо сделать. Хотя тестов на производительность в таком случае не делала, поэтому моё мнение можно назвать флудом :(
trigger
Разделение, конечно, хорошо, но к чему тогда PostgreSQL? Можно и чего-нибудь попроще. Потом вопрос где это разделение провести. По-моему, в "функциями базы" нужно обрабатывать только данные. Поручив же программе такую обработку, мы как раз смешаем логику и данные, а не разделим. Единственный вопрос: безопасность, SQL injections. Вот их не должна допустить программа.
 

[DAN]

Старожил PHPClub
trigger
Дело в том, что при обработке логов программа должна иметь актуальные на данный момент биллинговые данные (тарифный план, стоимость еденицы разговора и т.д.)
Соответственно, эти данные находятся в БД, и дергать их каждый раз при обработке звонка представляется мне невозможным.
Ладно, буду тестировать. Всем спасибо.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Если когда-нибудь возникнет вопросы обеспечения безопасности доступа к данным, масштабируемости или многопользовательского доступа - стоит использовать программирование базы.
Это намного более трудоемко, но при первом же внесении изменений в систему должно себя оправдать.

Разделение между приложением и базой лучше проводить на основе анализа экономической модели бизнес-процесса.
Стоит выделить, что в работе предприятия стабильно (форматы внутренних отчетов, например), что меняется часто (тарифы, сотрудники:), какие направления будут развиваться.
Сразу станет ясно, что где описывать.
 
Сверху