Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 8 [9] 10   вперед  Ctrl      все
 Re: Немного SQL перенести на хибер  [new]
mayton
Member

Откуда: loopback
Сообщений: 49763
Можно стабилизировать порядок mandatory переменных.
s.id, unsubscribe_date присутствуют всегда. Поднять их наверх.
Query query = em.createNativeQuery("select me.email , CAST (pc.poll_id as varchar ) , CAST ((select extract (epoch from me.unsubscribe_date)) as varchar ) " +
                "from space s " +
                "join \"user\" u on (s.id = u.space_id) " +
                "join poll p on (u.id = p.user_id) " +
                "join poll_channel pc on (p.id  =pc.poll_id) " +
                "join mailing m on (pc.id = m.poll_channel_id) " +
                "join mailing_list_email mle on (m.id = mle.mailing_id) " +
                "join mailing_email me on (mle.email_id = me.id) " +
                "where s.id = ? 
                "and me.unsubscribed = 'true' " +
                "and me.unsubscribe_date between ? and ? " +
                pollIdPredicate


А вариативная часть пойдет в конце.
17 ноя 20, 18:26    [22234060]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
mayton
Member

Откуда: loopback
Сообщений: 49763
И переменные.

                query.setParameter(1, spaceId);
                query.setParameter(2, fr);
                query.setParameter(3, to);
                if (request != null && request.getPid() != null) {
                            query.setParameter(4, Long.valueOf(request.getPid()));                            
                } 
17 ноя 20, 18:27    [22234062]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9249
Точнее так (псевдокод, поля не совпадают, могут быть опечатки)

StringBuilder sb;
..
if ( pid != null ) {
  sb.append( "and p.id = ? ";
}
if ( minDt != null ) {
  sb.append( "and dt >= ? ";
}
if ( maxDt != null ) {
  sb.append( "and dt <= ? ";
}
...
if ( pid != null) {
  query.setParameter( pos++, pid );
}
if ( minDt != null ) {
  query.setParameter( pos++, minDt );
}
if ( maxDt != null ) {
  query.setParameter( pos++, maxDt );
}
17 ноя 20, 18:28    [22234063]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9249
mayton

А вариативная часть пойдет в конце.

для конкретного запроса пойдет, но как принцип - не особо

3-и параметра для запроса, это как-то очень слабо. У нас до десятков точно доходило. В более-менее нормальном интерфейсе практически на любое поле должна быть возможность поставить условие IMHO & AFAIK. Если, конечно, среда разработки по умолчанию Query-by-example не предоставляет )))
17 ноя 20, 18:31    [22234064]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9249
mayton
А вариативная часть пойдет в конце.


когда практически все в запросе бывает вариативным, иногда специально делают mandatory часть:
sb.append( "SELECT...FROM...WHERE 1=1" );
if (...) {
  sb.append( " and .... " );
} 

В некоторых системах с непривычки это иногда удивляет, откуда и зачем 1=1, 2=2, 3=3 etc.. чисто для того, что бы с "and" не заморачиваться )))

Но я часто заводил специальный флаг, т.к. особой сложности с and нет, а селект все же более эстетически красивым получается. Ну и никто не мешает, весь это Building обернуть процедурами/ф-циями. Главное, что бы без фанатизма.
17 ноя 20, 18:40    [22234071]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 6525
Leonid Kudryavtsev
Главное, что бы без фанатизма.
угу.
А то скоро фреймворк получится.)
17 ноя 20, 18:43    [22234073]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 6525
Leonid Kudryavtsev
Я бы так делал:

pos = 1;
query.setParameter( pos++, spaceId );
if (request != null && request.getPid() != null) {
  query.setParameter( pos++, Long.valueOf(request.getPid()));
}
query.setParameter( pos++, fr );
query.setParameter (pos++, to );
+1
17 ноя 20, 18:45    [22234074]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
mayton
Member

Откуда: loopback
Сообщений: 49763
По сути тема данного обсуджения - торговля между сохранить StringBuilder еще на парочку релизов
или выкинуть все к еб...ням и переписать на MyBatis или Camunda как тут советует товарищ.
17 ноя 20, 18:50    [22234078]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 6525
mayton,
Да. Потому что фильтры магазинов это целые либы а не select+f+from+where
17 ноя 20, 19:01    [22234087]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
mayton
Member

Откуда: loopback
Сообщений: 49763
Для крупных магазинов - нужен фасетный поиск. По EAV. Да еще и с молниеносным
откликом. Типа показать все телевизоры с диагональю 34"", с двумя портами HDMI + Display,
в акции, да еще и чтоб Андроид был, да еще и чтоб был удобны пульты ДУ с кнопочками
для бабушки. Тут не то что трудно написать SQL а тут нужно принципиально другое
решение наподобие очень быстрого кеша + полнотекстового поиска + кластер БД.
17 ноя 20, 19:08    [22234091]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 6525
mayton,
Ну, модель хранения может быть и не EAV. Их полно всяких.
Но вот то что "принципиально другое", тут согласен.
17 ноя 20, 19:10    [22234094]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
mayton
Member

Откуда: loopback
Сообщений: 49763
Да. EAV может и не быть. Может быть JSON-документ. Может быть просто разветвлённая сеть таблиц
доменной модели. Но в крупных магазинах товары не имеют ограничений на спеку. Возьмите например
стиральную машинку. Или холодильник. И там можно сразу насчитать до 100 потребительских опций
и причем для холодильников и стиралок они почти не перескаются.
17 ноя 20, 19:16    [22234099]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 18324
я предлагал вариант без модификации sql-строки 22231682
чем не понравилось?
17 ноя 20, 21:01    [22234171]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9249
mayton
Для крупных магазинов - нужен фасетный поиск. По EAV. Да еще и с молниеносным
откликом. Типа показать все телевизоры с диагональю 34"", с двумя портами HDMI + Display,
в акции, да еще и чтоб Андроид был, да еще и чтоб был удобны пульты ДУ с кнопочками
для бабушки. Тут не то что трудно написать SQL а тут нужно принципиально другое
решение наподобие очень быстрого кеша + полнотекстового поиска + кластер БД.


Жесть какая.

Интересно, сколько в данном магазине одновременно товаров продается. Т.к. для пары десятков тысяч ( 50-100 тысяч) точно никакое "принципиально другое решение наподобие очень быстрого кеша + полнотекстового поиска + кластер БД" не требуется
IMHO & AFAIK

В 1998-1999 делал самописный полнотекстовый поиск по базе в 50 000 записей (современная версия http://iss.rybmuseum.ru/ от моего кода вряд ли что осталось, но мой код был ф-циональней, по крайне мере в результатах поиска еще совпадения подсвечивались /теперь не подсвечиваются ))) /) - все работало на "серверах" класса Celeron 400 Mz 16 Mg RAM. От PostgreSQL пришлось отказаться из-за тормознутости (vacuum) и перейти на MySQL ))).

Все занимало примерно 2-3 тысячи строк кода на Java.... но сейчас прогресс... без "принципиально другое решение" работать уже не может )))

Структура была EAV. Но весь поиск - чистый SQL на временных таблицах.
17 ноя 20, 21:37    [22234194]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9249
вадя
я предлагал вариант без модификации sql-строки 22231682
чем не понравилось?

несколько таких конструкций в результирующем запросе - запросто убьет и оптимизатор и план

AFAIK
17 ноя 20, 21:39    [22234196]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
mayton
Member

Откуда: loopback
Сообщений: 49763
Leonid Kudryavtsev
mayton
Для крупных магазинов - нужен фасетный поиск. По EAV. Да еще и с молниеносным
откликом. Типа показать все телевизоры с диагональю 34"", с двумя портами HDMI + Display,
в акции, да еще и чтоб Андроид был, да еще и чтоб был удобны пульты ДУ с кнопочками
для бабушки. Тут не то что трудно написать SQL а тут нужно принципиально другое
решение наподобие очень быстрого кеша + полнотекстового поиска + кластер БД.


Жесть какая.

Интересно, сколько в данном магазине одновременно товаров продается. Т.к. для пары десятков тысяч ( 50-100 тысяч) точно никакое "принципиально другое решение наподобие очень быстрого кеша + полнотекстового поиска + кластер БД" не требуется
IMHO & AFAIK

В 1998-1999 делал самописный полнотекстовый поиск по базе в 50 000 записей (современная версия http://iss.rybmuseum.ru/ от моего кода вряд ли что осталось, но мой код был ф-циональней, по крайне мере в результатах поиска еще совпадения подсвечивались /теперь не подсвечиваются ))) /) - все работало на "серверах" класса Celeron 400 Mz 16 Mg RAM. От PostgreSQL пришлось отказаться из-за тормознутости (vacuum) и перейти на MySQL ))).

Все занимало примерно 2-3 тысячи строк кода на Java.... но сейчас прогресс... без "принципиально другое решение" работать уже не может )))

Структура была EAV. Но весь поиск - чистый SQL на временных таблицах.

В 1999 году пользователи сидели на модемах. И в ваш магазин ходило полтора человека.

Ну вобщем как нельзя зайти в одну воду два раза, так и нельзя сравнить требования современного
магазина типа Amazon/Aliexpress/Ebay с магазином Пром-Товары вашего города.

Хотя я готов принять как факт что ваш магазин таки .. работал
17 ноя 20, 21:46    [22234203]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 18324
Leonid Kudryavtsev
несколько таких конструкций в результирующем запросе - запросто убьет и оптимизатор и план
проверял?
на таком простом запросе потери будут минимальны
17 ноя 20, 22:28    [22234228]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
mayton
Member

Откуда: loopback
Сообщений: 49763
вадя
Leonid Kudryavtsev
несколько таких конструкций в результирующем запросе - запросто убьет и оптимизатор и план
проверял?
на таком простом запросе потери будут минимальны

Здесь имеет место inner join из 6 таблиц. Тоесть если-бы мы кодили
эту задачу на java к примеру то у нас было-бы (грубо) 6!(факториал) = 720
возможных алгоритмов соединения (это без учета WHERE clause).

Тоесть план может прыгать. Не знаю как .. тут наверное MS-SQL .. он отрабатывает
подобные запросы.
17 ноя 20, 22:44    [22234233]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 18324
mayton
Здесь имеет место inner join из 6 таблиц.
ну и что?
where p.id= if(ifnull(pollId ),p.id,pollId )
разве if влиять?
17 ноя 20, 22:51    [22234238]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
mayton
Member

Откуда: loopback
Сообщений: 49763
Мда. Может быть. Если s.id селективен то наверное имеет смысл начинать с фильтра по space.
Если-бы предложения WHERE не сущестовало то тогда мы-бы делали просто различную эвристику
над внешними и прочими ключами.
17 ноя 20, 23:08    [22234247]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
Zzz79
Member

Откуда:
Сообщений: 1005
вадя
я предлагал вариант без модификации sql-строки 22231682
чем не понравилось?

не совсем понял как в такой конструкции сделать биндинг
тоесть вот этот знак '?' надо куда то ставить и далее делать query.setParameter(1,pollId)

твой фильтр выглядит вот так

where p.id= if(ifnull(pollId ),p.id,pollId )

тоесть в моем варианте он должен выглядеть как то так
where p.id= if(ifnull(? ),p.id,? )

тогда уже будет два биндинга или как ты предлагаешь?
в nativeQuery в любом случае так или иначе надо значения биндить и я не понял как это осуществить в данном конкретном случае
18 ноя 20, 10:02    [22234386]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
Zzz79
Member

Откуда:
Сообщений: 1005
mayton
Можно стабилизировать порядок mandatory переменных.
s.id, unsubscribe_date присутствуют всегда. Поднять их наверх.
Query query = em.createNativeQuery("select me.email , CAST (pc.poll_id as varchar ) , CAST ((select extract (epoch from me.unsubscribe_date)) as varchar ) " +
                "from space s " +
                "join \"user\" u on (s.id = u.space_id) " +
                "join poll p on (u.id = p.user_id) " +
                "join poll_channel pc on (p.id  =pc.poll_id) " +
                "join mailing m on (pc.id = m.poll_channel_id) " +
                "join mailing_list_email mle on (m.id = mle.mailing_id) " +
                "join mailing_email me on (mle.email_id = me.id) " +
                "where s.id = ? 
                "and me.unsubscribed = 'true' " +
                "and me.unsubscribe_date between ? and ? " +
                pollIdPredicate


А вариативная часть пойдет в конце.

а с точки зрения самого запроса это норм будет ? бд нет разницы в каком порядке фильтры идут?ибо если она фильтрует по порядку - то сначала выберет все с датами всех пулов - а мне нужен пул определенный- как это с точки производительности будет выглядеть
?
18 ноя 20, 10:05    [22234387]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
Zzz79
Member

Откуда:
Сообщений: 1005
mayton
И переменные.

                query.setParameter(1, spaceId);
                query.setParameter(2, fr);
                query.setParameter(3, to);
                if (request != null && request.getPid() != null) {
                            query.setParameter(4, Long.valueOf(request.getPid()));                            
                } 

вот этот вариант самый читаемый для пользователя,все-таки инкрементация в биндинге такое себе.
Осталось понять не повлияет ли это на производительность ,так как по уму сначала фильтруем по группе( spaceId) потом по опросу( pollId) потом по датам уже ,не получится ли так что мы при введеном pollId все равно сначала и только потом фильтранем по pollId
либо же where запрос работает как единое целое и ему пох в каком порядке стоят фильтры.
18 ноя 20, 10:19    [22234396]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
Zzz79
Member

Откуда:
Сообщений: 1005
Leonid Kudryavtsev
Точнее так (псевдокод, поля не совпадают, могут быть опечатки)

StringBuilder sb;
..
if ( pid != null ) {
  sb.append( "and p.id = ? ";
}
if ( minDt != null ) {
  sb.append( "and dt >= ? ";
}
if ( maxDt != null ) {
  sb.append( "and dt <= ? ";
}
...
if ( pid != null) {
  query.setParameter( pos++, pid );
}
if ( minDt != null ) {
  query.setParameter( pos++, minDt );
}
if ( maxDt != null ) {
  query.setParameter( pos++, maxDt );
}


не многовато ли if?где то я читал ,помоему в чистом коде,что если у тебя больше двух ифов - код автоматически превращается в г0вно
18 ноя 20, 11:02    [22234420]     Ответить | Цитировать Сообщить модератору
 Re: Немного SQL перенести на хибер  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 6525
Zzz79,
1 про количество if и наличие циклов ерунда. Так 16ти летки говорят.
2. скорость запроса и тюнинг после цифр о том что там не устраивает.
18 ноя 20, 11:06    [22234425]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 8 [9] 10   вперед  Ctrl      все
Все форумы / Java Ответить