может быть примерно таким:
[
{
"id": 1,
"a": 256,
"b": 100,
"c": 900000000,
"d": "hello guys"
},
{
"id": 2,
"a": 257,
"b": 100,
"c": 800000000,
"d": "hello guys again"
},
{
"id": 3,
"a": 258,
"b": 100,
"c": 700000000,
"d": "hello guys once again"
}
]
Т.е. массив из обновляемых объектов: находим по айди, и обновляем другие поля.
Максимальное количество таких элементов: 2000 штук.
Получается, если перебирать каждый из них, можно обновить все сущности за 2000 запросов в БД.
Это самый простой вариант, но не думаю что это лучший.
Искал способы сделать это одним запросом, нашел пару заклинаний на SQL с использованием CASE id WHEN 1 then ... WHEN 2 then ...
Хочу уточнить у вас, стоит ли продолжать мысль в этом направлении? Есть ли другие способы это реализовать?
Или не париться и делать перебором?
В общем рад любому совету по оптимизации этой задачи 🙏
Такую задачу можно решить с помощью Upsert, которая позволит вам удобно обновить или синхронизировать большой объем данных одним запросом. Метод Upsert делает insert записей, которых нет в базе и update для тех что есть.
Не вариант бро, логика создания и обновления разделена
Я бы положил во временную таблицу и сделал бы UPDATE .... FROM tempory_table t WHERE id = t.id
Максимум 2000 записей, со всей валидацией на обновление уходит примерно 8000 запросов в бд
Что-то типа джобов? Очереди?
Валидатор можно кастомный на весь массив
Даже без очереди пролетит за миллисекунды
++ Да, работаю над этим, много запросов уменьшил
В чем цель оптимизации, разогнуть пальцы и показать какой я молодец и все сделал одним запросом, но приэтом потратить на него неделю времени разработчика (за эти деньги можно vps помощнее на год взять). Или если прилетит доробатка через пару месяцев и придется другому разбираться в вашей мегаоптимизации, сколько времени займет добавление новых колонок или доп. проверки. А по итогу оказывается выиграли на рантайме 500-600 милисекунд, а запрос делают один раз сутки. Стоит ли оно того? Оценят ли ваши усилия?
... Согласен, спорить не могу, аргументов нет, признаюсь ) Цель в том, что по старой логике сервак не выдерживал и часто отказывал. Вот и хотел улучшить по максимуму. С вашей мыслью вполне согласен, из своего опыта знаю: удобный код очень важен) Спасибо за советы ребят 🙏 Рад что такие парни есть )
Обсуждают сегодня