AR
На PHP - только не забывать открывать транзакицю и лок брать
Size: a a a
2020 March 06
АЧ
На PHP - только не забывать открывать транзакицю и лок брать
Хорошо. Сделаю на ПХП. Но все таки для общего понимания. Сделал на ПХП создание расписания для мастера (Несколько сот запросов. Большинство на запись). Отрабатывало пару сек. Пришлось уносить в очередь и делать заставку на фронте. Написал хранимую процедуру - 10-15 мс. Мне кажется в последнем случае БД менее нагружена? Или Ошибаюсь? Правда БД вообще не настраивал (postgreSQL)
A
Хорошо. Сделаю на ПХП. Но все таки для общего понимания. Сделал на ПХП создание расписания для мастера (Несколько сот запросов. Большинство на запись). Отрабатывало пару сек. Пришлось уносить в очередь и делать заставку на фронте. Написал хранимую процедуру - 10-15 мс. Мне кажется в последнем случае БД менее нагружена? Или Ошибаюсь? Правда БД вообще не настраивал (postgreSQL)
Может ты забыл что инсерты можно группировать?
AR
Создание расписания, как я понимаю это много-много инсертов в БД. Я бы посмотрел в сторону оптимизации так чтобы одним запросом сразу много записей создавать
A
Создание расписания, как я понимаю это много-много инсертов в БД. Я бы посмотрел в сторону оптимизации так чтобы одним запросом сразу много записей создавать
Я был раньше :)
EG
Создание расписания, как я понимаю это много-много инсертов в БД. Я бы посмотрел в сторону оптимизации так чтобы одним запросом сразу много записей создавать
если транзакция кол-во инсертов не влияет на скорость, т.к. потом это все разом будет загружена когда транзакцию будет commit
AR
я не уверен за синтаксис postgresql, но в MySQL это как insert into table (field1, ..., fieldN) VALUES (val1_1, ..., val1_N), ... , (valM_1, ..., valM_N);
АЧ
Создание расписания, как я понимаю это много-много инсертов в БД. Я бы посмотрел в сторону оптимизации так чтобы одним запросом сразу много записей создавать
Если бы только инсерты! Там надо проверять перед каждым некоторые условия.
AR
При много-много запросов основное время уходит на раундтрипы до БД и обратно
АЧ
При много-много запросов основное время уходит на раундтрипы до БД и обратно
В том то и дело
AR
Мы не знаем твоего ТЗ и говорим тебе как лучше выглядит исходя из имеющихся у нас данных
АЧ
И хочется понять, где та грань после которой лезть в базу!
AR
И хочется понять, где та грань после которой лезть в базу!
в 99% случаях - не надо лезть в БД чтобы писать процедуры :)
A
Если бы только инсерты! Там надо проверять перед каждым некоторые условия.
Ты наверняка можешь накопить эти инсерты
AR
а тот единственный 1% - это реально исключительные случаи и они скорее где-то в жоском ынтырпрайзе
EG
При много-много запросов основное время уходит на раундтрипы до БД и обратно
в данном случае если это расписание, то максимум 365x2 запросов, это мелочь, да и запросы скорее всего будут смешные
AR
в данном случае если это расписание, то максимум 365x2 запросов, это мелочь, да и запросы скорее всего будут смешные
ну 365*2 > 1*2 :)
АЧ
а тот единственный 1% - это реально исключительные случаи и они скорее где-то в жоском ынтырпрайзе
😊
AR
Как сказал выше @Adelf32 - тебе действительно надо смотреть на логику и скорее подкопить инсерты и пачками их вносить
AR
Пятница, отпуск, бесплатные советы :)