Java 17 Released

Ваша история напоминает анекдот.
- Как взломать банковский сейф?
- Берешь ноут и динамит. Обкладываешь сейф динамитом и взрываешь.
- Вопрос: А зачем ноут?
- Ответ: А какой же ты хакер без ноута.

Так вот ваш XML - это почти тот самый ноут.

Как правильно сделать я и сам знаю, но проект загажен ОРМ а результат нужен быстро.

А как сделать по другому не переписывая пол проекта?

И я не какер а контрактов.
Мне чем меньше понтов, тем лучше.

Я одно время на жаба забил, так она совсем заплесневела и стало просто скучно.

Да и теперь при наличии Скала за жару берусь когда ничего интересного нет.

Для себя - няку.

А! «Херак-херак и продакшен». Сочувствую.

Всё равно не понимаю, зачем там XML. Если вы упираетесь в качество и скорость работы какого-то конкретного парсера, то это не преимущество и не недостаток XML. Это качество парсера. То что какие-то технологии заточены вокруг XML, это опять не их преимущества. Скорее наоборот. Их бы все закопать, но слишком много денег в них уже вложено и процесс их медленного закапывания затянется на долгие-долгие годы, возможно даже на сотню-другую лет. Но в пределе XML умирает полностью, утягивая за собой www в том виде, в котором оно есть сейчас.

Выше пояснили. Как было раньше. Долбичка, в ней столбец, в долбичке 300к записей. Для изменения достаточно одного update.
Как модно теперь. 300к записей размазываем неравномерным слоем на пару сотен таблиц, по разным столбцам в которых ещё храниться куча другой информации. Как из этой мешанины цифирек и букавок получить те самые 300к записей не помнят даже девелоперы. Всё обмазано в несколько тысяч слоев абстракций. И вот для того самого апдэйта, теперь надо дергать вооон тут пипку, которая дернет, которые дёрнут...не, а чё такого? Процы шустрые, мозгов много, будут жаловаться что медленно, скажем меняйте/докупайте камни, не скупитесь на мозги...а мы пока очередной апдэйт тут мастрячим... что бы не казалось, что наша программа ничего не делает. Ещё как делает! Вон видите те 10 процессов которые третьи сутки камень на 100% грузят? Это они 2+2 считают.
И такая дребедень...

Так это говнокод просто. И говноархитектура. Нормализация и размазывание - хорошо. Но когда производительность упирается, то специально назад денормализируют базу. Так можно дойти до того, что для сохранения даты надо табличку на день, табличку на месяц, табличку на год...

Так это говнокод просто. И говноархитектура.

Нэповерите... и оно процветает полным ходом уже третий десяток лет.

Нормализация

Не в этом случае. Здесь таких слов отродясь не слышали.

для сохранения даты надо табличку на день, табличку на месяц, табличку на год

Зачем? Чем просто три столбца не устраивают?

Ну а как же. Вдруг известен только день? А вдруг только месяц? А может только год рождения?

Если поля опциональные, тогда да, согласен. Хотя в современных СУБД поддерживаются поля NULL, по сути необходимости в такой нормализации нет.

Необходимости то нет. Но вот некоторые считают что NULL поля это вообще зло, как goto (а для выхода из вложенных циклов ничего лучше нету), которым не место в БД.

Но вот некоторые считают что NULL поля это вообще зло

Странные люди индейцы... это какой-то промежуток видимо, чутка откусили от табличного варианта и чутка от субд, в результате всё смешалось в их голове, утверждают некие тезисы как аксиомы без попытки их осмыслить.
Точно, вспомнил, это заставшие таблички, а точнее dbf. У них null очень плохо в голове укладывается.

Настойчиво предложи таким людям хранить всё в одном поле в JSON. Их хватит кондратий и можно будет спокойно делать что хочешь.

Вы уж определитесь по какому поводу мне сочуствуете.

А то пока ни одна ваша фантазия не оправдались ;)

Всё равно не понимаю, зачем там XML.

Чтобы передать параметры в ДБ

Если вы упираетесь в качество и скорость работы какого-то конкретного парсера, то это не преимущество и не недостаток XML.

При чем здесь парсер?

В моем случае мне нужно передать много параметр в ДБ.

Другого нормального способа нет.

Но в пределе XML умирает полностью, утягивая за собой www в том виде, в котором оно есть

Не понял.
Зачем XML умирать?
Как он тянет www?

this

но проект загажен ОРМ

И какое это имеет отношение к вашим высказываниям?

Я ННП

ОРМ == «Херак-херак и продакшен» Вам приходиться с тем что слепили как-то крутиться. Это неприятно.
Надеюсь понятно пояснил.

ОРМ == «Херак-херак и продакшен»

А как вы предлагаете делать проект при жестокой нехватке программистов?

Я, в принципе могу им устроить краш-курс по SQL, но чтобы нормально с ним работать нужно несколько лет.
А ОРМ может использоваться среднестатистическим кодером, который кроме одного ЯП ничего не знает.

Т.е. ОРМ бывает необходим

Вам приходиться с тем что слепили как-то крутиться. Это неприятно.

Почему?
Я считаю что нашёл оптимальное решение и с минимумом усилий и без ломки проекта.
Весьма приятно.

А как бы вы поступили в такой ситуации?

А ОРМ может использоваться среднестатистическим кодером, который кроме одного ЯП ничего не знает.

С соответствующим результатом.

Я считаю что нашёл оптимальное решение и с минимумом усилий и без ломки проекта.

У вас это кусок входящий в какой-то другой проект?

А как бы вы поступили в такой ситуации?

Я не знаю условия задачи. Написал варианты, стер. Я не знаю условия задачи.

С соответствующим результатом.

Результат хороший, если проект работает.
Кроме того, как сказал мне оди большой босс, когда я предложил добавить несколько СП в проект:
– У тебя контракт закончится, и кто будет их поддерживать?

У вас это кусок входящий в какой-то другой проект?

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

Я не знаю условия задачи. Написал варианты, стер. Я не знаю условия задачи.

Есть большой проект.
Нужно ускорить несколько схожих операций которые меняют большой объём данных по достаточно сложным выборкам. Есть место в коде где id записей уже есть в памяти. до 1м
СП никто не использует.

Результат хороший, если проект работает.

[лирика-on] Например при работе с данными встречается такая неприятная штука, как экспоненциальное падение производительности. Изначально запланировали и протестировали нагрузку равной N. Всё устраивает. Живем год, живем два, живем три, ну чутка повышается нагрузка относительно изначальной. А потом внезапно приходит белый пушистый зверек. Причин может быть масса. От банального мы и забыли про то самое тестовое N, а у нас уже давно N*M. До, однако во время пути проект мог подрасти и тестовое N давно равно площади сферического коня в вакууме. [лирика-off]

Нужно ускорить несколько схожих операций которые меняют большой объём данных по достаточно сложным выборкам. Есть место в коде где id записей уже есть в памяти. до 1м

id это индексное поле в базе или сферическое в орм?
Не ужимаются? Я про поделить на последовательности.

СП никто не использует.

А должно помочь? Кто за субд кстати?

ЗЫ Банальщина. На блокировках не подвисает случайно? А то бывает «любят» запихнуть выборку и изменение в одну транзакцию.

Проблема была в том, что ОРМ обрабатвал записи по одной, так как набор построение выборки могло быть сложным.

изменение - одна-три но иногда с несколькими таблицами.

ID - значение индексированного поля.

ПС
Мне на самом деле решение не очень нужно, так как все работает.

На расстоянии все могут себя героми выставлять и критиковать чужие решения, но занятно наблюдать как вы начинаете понимать задачу ;)