1) enum применять только в тех случаях, когда добавление нового значения влияет на изменение кодовой базы сервиса.
2) использование только внутреннее, без демонстрации пользователю. Чтобы, например, не заморачиваться с тем, откуда достать текстовое описание значения.
Если хоть одно из условий не выполняется, нужно использовать таблицы. То есть примерно в 99% случаев, если не больше
Задача была именно такая: найти запись по сотруднику с максимальным score
Решение изумило: скачивали на клиента при каждом запросе (нагрузка была примерно 200 tps) около 20 строк, руками пробегали этот список и находили строку с максимальным значением, и брали все атрибуты именно с неё.
Любой инструмент должен быть применен по назначению. В том числе и хранимые процедуры.
Текст процедур вообще ничем не отличается от текста на, к примеру, Java. Его можно прекрасно положить в GIT и так же версионировать. И точно так же документировать, точно так же тестировать на тестовой бд.
Единственный значимый аргумент - это привязка к конкретной СУБД. И то каждый сам для себя определяет допустимую степень риска. Кому было нужно - потратили время и деньги и перешли с oracle/mssql. Значит, задача не является нерешаемой.
Паническое нежелание работать с ХП иногда приводит к маразму. Настолько разработчики боятся малейшей логики в бд, что вместо select max(...), загружают список записей на клиента и уже там находят максимальное значение нужного поля (сам видел)
2) Нет ci/cd? Для финтеха сомнительно, ну ладно. Нужно выбивать. У меня в лохматые годы тоже не было. Ничего, не обломался, поднял tfs, Тим сити. Они бесплатные. Потом посмотрели, подняли на уровень управления
3) Работа не повышает квалификацию? Есть курсы, конференции, разработка пет-проектов.
Собственно, enterprise-программирование - это не искусство, а, в первую очередь, ремесло. Нужно искусство - смотри стартапы или отделы r&d
И такой код просто отключает индекс по полю CreatedDate.
Логичный и ясный запрос в orm не всегда является таковым с точки зрения оптимальности запроса sql.
Актуальность orm продается под соусом избавления программиста от знания sql. Но по факту программист должен знать и sql, и особенности orm. Двойная работа.
Поэтому мне больше по душе легковесные orm типа dapper, которые занимаются именно маппингом объектов, оставляя логику написания запроса программисту
"Вы предлагаете запросу, с одной транзакцией случайно сгенерировать ранг 7539 и ждать, пока 7538 транзакций отработают, пока кукушонку не дойдет очередь.": Именно так, ведь мы исходим из предположения, что все транзакции равноправны. Иных вводных то нет. Поэтому уравниваем вероятности исполнения транзакций.
Конечно, если всего 2 клиента, по 1 транзакции и 10к транзакций, то такие коллизии возможны. Но когда одиночных транзакций становится побольше, среднее время ожидания уменьшается
Есть ещё вариант: реализовать список из клиентов, где у каждого клиента своя очередь транзакций. И можно выбирать поочередно из каждой очереди сообщения. Этот вариант более лоялен к клиентам с мелкими транзакциями. А крупняки получат могут получить приличную задержку.
Вариант 3 - это вариация варианта 2: оценивать при вычитывании размер очереди. Чем больше размер очереди, тем больше у этой очереди приоритет вычитывания транзакций. И после каждого вычитывания пересчитывать приоритеты
Получится примерно так-2 клиента: 10к транзакций и 100 транзакций. И на каждую 1000 транзакций из первой очереди считаем 10 транзакций из второй. Этот вариант позволяет уровнять время обслуживания всех клиентов.
Я может чего не понял в постановке, но что мешает получить сообщение с транзакциями (без учёта их количества) и по одной записывать в ту же кафку? Тогда сообщения от всех клиентов будут равномерно перемешаны с учётом времени прихода. И также горизонтально масштабируется путем создания нужных партий и увеличения консьюмеров
Если же требуется "размазать" условные 10к транзакций по периоду, и в эту кашу подкидывать транзации-кукушата, то нужно придумать функцию, которая ранжирует транзации. В простейшем варианте - генератор равномерно распределенных случайных чисел.
Грубо говоря - получили 10к транзакций. Присваиваем каждой из них случайное число в диапазоне 0..100к и пишем их в БД.
Вычитываем топ N транзакций, отправляем на исполнение, а у оставшихся транзакций в бд уменьшаем ранжирование на величину, равную минимальному оставшемуся значению (это позволит уменьшить время ожидания самых последних транзакций)
То есть вычитали скажем одну, самую низкоранговую транзакцию с рангом 157. Следующая транзакция например 301. Тогда у всех остальных ранг понизили на 301. И транзация 301 стала транзакцией с нулевым рангом.
Метод работает хорошо, если скорость исполнения транзакций значительно превышает скорость их прихода.
PS только обратил внимание, что gandjustas предложил в принципе то же самое со своей функцией долга
1) делаем справочник вместо перечислений, если изменение списка допустимых значений не приводит к необходимости доработки существующего кода
2) используем enum, если каждое изменение перечня значений - это изменение функциональности в коде, и выводится на пром релизом, в котором учтены скрипты миграции
А зачем просиживать штаны? Почему бы и не развиваться там, где распределен?
Я по своему опыту и говорю - попал в НИИ, прекрасно себя чувствовал, + похалтуривал. 5 лет прошло, спокойно ушел в банк работать.
Вам не кажется, что человек, просиживающий штаны в НИИ, будет точно также просиживать в коммерции? И доход у такого человека всегда будет невпечатляющий
Из своего опыта:
1) enum применять только в тех случаях, когда добавление нового значения влияет на изменение кодовой базы сервиса.
2) использование только внутреннее, без демонстрации пользователю. Чтобы, например, не заморачиваться с тем, откуда достать текстовое описание значения.
Если хоть одно из условий не выполняется, нужно использовать таблицы. То есть примерно в 99% случаев, если не больше
Платные версии в первую очередь приобретают из-за технической поддержки
Можно и так. В любом случае, запрос будет быстрее и нагляднее, чем грузить рекордсет на клиента. Даже странно, что приходится объяснять очевидное
Типа такого:
Select *
From example_table t1
Where t1.empl = 123
And t1.score = (select max(score) from example_table t2 where t2.empl = 123)
Order by id desc
Limit 1
Пишу с телефона, уж простите, не форматирую текст
Задача была именно такая: найти запись по сотруднику с максимальным score
Решение изумило: скачивали на клиента при каждом запросе (нагрузка была примерно 200 tps) около 20 строк, руками пробегали этот список и находили строку с максимальным значением, и брали все атрибуты именно с неё.
Любой инструмент должен быть применен по назначению. В том числе и хранимые процедуры.
Текст процедур вообще ничем не отличается от текста на, к примеру, Java. Его можно прекрасно положить в GIT и так же версионировать. И точно так же документировать, точно так же тестировать на тестовой бд.
Единственный значимый аргумент - это привязка к конкретной СУБД. И то каждый сам для себя определяет допустимую степень риска. Кому было нужно - потратили время и деньги и перешли с oracle/mssql. Значит, задача не является нерешаемой.
Паническое нежелание работать с ХП иногда приводит к маразму. Настолько разработчики боятся малейшей логики в бд, что вместо select max(...), загружают список записей на клиента и уже там находят максимальное значение нужного поля (сам видел)
Всегда есть что сделать
1) Нет документации? Так начинай вести
2) Нет ci/cd? Для финтеха сомнительно, ну ладно. Нужно выбивать. У меня в лохматые годы тоже не было. Ничего, не обломался, поднял tfs, Тим сити. Они бесплатные. Потом посмотрели, подняли на уровень управления
3) Работа не повышает квалификацию? Есть курсы, конференции, разработка пет-проектов.
Собственно, enterprise-программирование - это не искусство, а, в первую очередь, ремесло. Нужно искусство - смотри стартапы или отделы r&d
Полнотекстовый поиск
И такой код просто отключает индекс по полю CreatedDate.
Логичный и ясный запрос в orm не всегда является таковым с точки зрения оптимальности запроса sql.
Актуальность orm продается под соусом избавления программиста от знания sql. Но по факту программист должен знать и sql, и особенности orm. Двойная работа.
Поэтому мне больше по душе легковесные orm типа dapper, которые занимаются именно маппингом объектов, оставляя логику написания запроса программисту
Какой-то странный выверт сознания. В Сбере ИТшники как раз и имеют возможность сидеть на удалёнке.
И очень много людей с регионов
Тут я не согласен. Возвращать 200 на любой чих можно и в REST. Это не косяк RPC, а кривые руки разработчика.
ЗЫ А так вообще приятно видеть знакомые ники с sql ru
Пришлось делать получение объектов через post /objects/get - сложные фильтры с массивами через тело передаю
В итоге если остальные методы делать как rest - будет некрасиво и не единообразно
Решил тогда всю api-шку сделать как rpc:
Все методы post, глагол в конце url, все идентификаторы - как query параметры
Ну и в этой парадигме в тему пришлось создание сразу нескольких объектов в одном запросе
Кажется, не то же самое. Отдельный инстанс на мелкие транзакции неравно отдельному инстансу на клиента
"Вы предлагаете запросу, с одной транзакцией случайно сгенерировать ранг 7539 и ждать, пока 7538 транзакций отработают, пока кукушонку не дойдет очередь.": Именно так, ведь мы исходим из предположения, что все транзакции равноправны. Иных вводных то нет. Поэтому уравниваем вероятности исполнения транзакций.
Конечно, если всего 2 клиента, по 1 транзакции и 10к транзакций, то такие коллизии возможны. Но когда одиночных транзакций становится побольше, среднее время ожидания уменьшается
Есть ещё вариант: реализовать список из клиентов, где у каждого клиента своя очередь транзакций. И можно выбирать поочередно из каждой очереди сообщения. Этот вариант более лоялен к клиентам с мелкими транзакциями. А крупняки получат могут получить приличную задержку.
Вариант 3 - это вариация варианта 2: оценивать при вычитывании размер очереди. Чем больше размер очереди, тем больше у этой очереди приоритет вычитывания транзакций. И после каждого вычитывания пересчитывать приоритеты
Получится примерно так-2 клиента: 10к транзакций и 100 транзакций. И на каждую 1000 транзакций из первой очереди считаем 10 транзакций из второй. Этот вариант позволяет уровнять время обслуживания всех клиентов.
Я может чего не понял в постановке, но что мешает получить сообщение с транзакциями (без учёта их количества) и по одной записывать в ту же кафку? Тогда сообщения от всех клиентов будут равномерно перемешаны с учётом времени прихода. И также горизонтально масштабируется путем создания нужных партий и увеличения консьюмеров
Если же требуется "размазать" условные 10к транзакций по периоду, и в эту кашу подкидывать транзации-кукушата, то нужно придумать функцию, которая ранжирует транзации. В простейшем варианте - генератор равномерно распределенных случайных чисел.
Грубо говоря - получили 10к транзакций. Присваиваем каждой из них случайное число в диапазоне 0..100к и пишем их в БД.
Вычитываем топ N транзакций, отправляем на исполнение, а у оставшихся транзакций в бд уменьшаем ранжирование на величину, равную минимальному оставшемуся значению (это позволит уменьшить время ожидания самых последних транзакций)
То есть вычитали скажем одну, самую низкоранговую транзакцию с рангом 157. Следующая транзакция например 301. Тогда у всех остальных ранг понизили на 301. И транзация 301 стала транзакцией с нулевым рангом.
Метод работает хорошо, если скорость исполнения транзакций значительно превышает скорость их прихода.
PS только обратил внимание, что gandjustas предложил в принципе то же самое со своей функцией долга
Возможно, комментатор предположил, что это гастролирующая пиццерия, которая готовит пиццу на оборудовании заказчика?
Или порядок приготовления пиццы отличается в зависимости от рецептуры
Сбер большой. Команд много. Кто то канбанит, кто то скрамит, кто то свое придумывает. У каждой команды свои практики.
Мы следуем следующей логике.
1) делаем справочник вместо перечислений, если изменение списка допустимых значений не приводит к необходимости доработки существующего кода
2) используем enum, если каждое изменение перечня значений - это изменение функциональности в коде, и выводится на пром релизом, в котором учтены скрипты миграции
Сильное заблуждение. Есть там спецы, и очень хорошие.
А зачем просиживать штаны? Почему бы и не развиваться там, где распределен?
Я по своему опыту и говорю - попал в НИИ, прекрасно себя чувствовал, + похалтуривал. 5 лет прошло, спокойно ушел в банк работать.
Вам не кажется, что человек, просиживающий штаны в НИИ, будет точно также просиживать в коммерции? И доход у такого человека всегда будет невпечатляющий