Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Работа Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 19 20 [21] 22 23   вперед  Ctrl
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
zeehond
Алексей К
Я тебе показал какие запросы генерируют дотнетные ОРМы под MSSQL.


какой ужас, а зачем так сложно?
т.е. просто передать строку запроса с плейсхолдерами на месте параметров - не получается?
См моё предыдущее сообщение.
13 июн 12, 11:51    [12706618]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
DeathHand
Алексей К
пропущено...
Почему?

Ну, если это все, что у Вас есть для оптимизации относительно плана - то не айс :)
Чего не хватает?
13 июн 12, 11:54    [12706631]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54517
Блог
sphinx_mv
Вопрос, только в том, как закэшированные планы запросов помогут, если запросы "по факту" не одинаковы...
Запрос 1
select * FROM TBL WHERE FLD = 'всякая фигня 1'
SELECT * from TBL where FLD = 'всякая фигня 1'
select* FRom TBL where fld = 'всякая фигня 2'
SELECT * From tbl where FLD = 'всякая фигня 2'

Это одинаковые запросы? А вот и НЕТ! (даже если и по-парно) Они просто ПОХОЖИ...
А планы у них одинаковы? Возможно, но очень не факт...
Для РАЗНЫХ запросов необходимо компилировать свой СОБСТВЕННЫЙ план...

Ну на самом деле работа СУБД в этом случае зависит от того, какая именно СУБД и как настроена. Например, Oracle, в зависимости от настроек, воспримет это либо как два разных запроса, либо как один.
13 июн 12, 11:58    [12706644]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
DeathHand
Member

Откуда: Мск>СПБ>Врн
Сообщений: 2705
Алексей К
DeathHand
пропущено...

Ну, если это все, что у Вас есть для оптимизации относительно плана - то не айс :)
Чего не хватает?

У Вас есть возможность смотреть по курсору - какой этап плана выполняется им в данный момент?
13 июн 12, 12:00    [12706658]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
DeathHand
Алексей К
пропущено...
Чего не хватает?

У Вас есть возможность смотреть по курсору - какой этап плана выполняется им в данный момент?
Не знаю, может и есть. Но как это относится к обсуждаемому вопросу про кэширование планов выполнения динамических запросов?
13 июн 12, 12:02    [12706669]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
Андрей Панфилов
sphinx_mv,

успокойтесь, разные версии jdk лежат в разных каталогах и никому не мешают, проблемы только в майкрософте и то только в браузерах, т.е. древней клиентской части.

То есть, теперь MS виноват еще и в проблемах совместимости разных билдов Java! Афигеть! Дайте две!
Балмер в курсе?

Не настолько у Вас богатый опыт "общения" со чужими java-приложениями...

Или Вы действительно считаете, что при выборе двух инсталяций одного и того же продукта я должен ВСЕГДА выбирать ту инсталяшку, которая включает в себя JDK? А почему мне кажется, что нет?
Соотвественно, скачав то, что без JDK, (последнюю самую свежую и очень недавнюю версию) получил при запуске, что нужен не тот JDK, который уже установлен в системе, а другая версия... При этом более старая... Ладно... Скачал... Утановил...
Не одним java-приложением приходится пробовать...
Следующая итерация с другим продуктом... И тоже без JDK скачивал... Этому уже понадобилась более новая версия JDK. Скачал... Установил... Что собственно, весьма ожидаемо - "сломалось" первое приложение...
И при есть еще приложения, которые прекрасно работают со стандартно установленным в системе (отдельным) JDK...

После подобных танцев с бубнами приходится качать вместе с JDK...
Проблемы совместимости прекратились, а вот осадок - остался...

А теперь сравниваем с .net, под которым приложению не надо за собой таскать и устанавливать отдельную копию фреймворка с нужной, "совместимой" версией...
13 июн 12, 12:22    [12706777]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 2935
sphinx_mv
То есть, теперь MS виноват еще и в проблемах совместимости разных билдов Java! Афигеть! Дайте две!
ну по большому счету да, проблема больше в microsoft нежели в jvm - довольно тяжко меняются переменные окружения. Может еще от разработчиков зависит, вот, к примеру, в эклипсе (терпеть его не могу) можно задать какую именно vm использовать: http://wiki.eclipse.org/Eclipse.ini
13 июн 12, 12:35    [12706887]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54517
Блог
Андрей Панфилов
ну по большому счету да, проблема больше в microsoft нежели в jvm - довольно тяжко меняются переменные окружения.

Переменные окружения - это тяжкое наследие однозадачного досовского прошлого. По-хорошему их давно надо было бы выкинуть, бесполезный геморрой.
13 июн 12, 12:42    [12706930]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
softwarer
sphinx_mv
Вопрос, только в том, как закэшированные планы запросов помогут, если запросы "по факту" не одинаковы...
Запрос 1
select * FROM TBL WHERE FLD = 'всякая фигня 1'
SELECT * from TBL where FLD = 'всякая фигня 1'
select* FRom TBL where fld = 'всякая фигня 2'
SELECT * From tbl where FLD = 'всякая фигня 2'

Это одинаковые запросы? А вот и НЕТ! (даже если и по-парно) Они просто ПОХОЖИ...
А планы у них одинаковы? Возможно, но очень не факт...
Для РАЗНЫХ запросов необходимо компилировать свой СОБСТВЕННЫЙ план...

Ну на самом деле работа СУБД в этом случае зависит от того, какая именно СУБД и как настроена.

В том то и дело, знает ли об этом какой-нибудь hibernate...
С учетом подхода "бд нам нафиг не нужна" - вряд ли...
softwarer
Например, Oracle, в зависимости от настроек, воспримет это либо как два разных запроса, либо как один.

Да. Вот только в некоторых случаях настройка "как один" не всегда дает хорошие результаты...
13 июн 12, 12:43    [12706941]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
DeathHand
Member

Откуда: Мск>СПБ>Врн
Сообщений: 2705
sphinx_mv
Да. Вот только в некоторых случаях настройка "как один" не всегда дает хорошие результаты...

Проще их всех (явистов) - посадить за Rule Пускай делают, че хотят. У них и так все тормозит и виновата СУБД.
13 июн 12, 12:48    [12706988]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54517
Блог
sphinx_mv
Да. Вот только в некоторых случаях настройка "как один" не всегда дает хорошие результаты...

Не всегда, конечно. Я в данном случае ткнул пальцем в не очень верное утверждение, оставив в стороне тот момент, что этот аспект вообще не имеет отношения к "звенности" и "ормности".
13 июн 12, 12:49    [12706989]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
sphinx_mv
softwarer
пропущено...

Ну на самом деле работа СУБД в этом случае зависит от того, какая именно СУБД и как настроена.

В том то и дело, знает ли об этом какой-нибудь hibernate...
С учетом подхода "бд нам нафиг не нужна" - вряд ли...
softwarer
Например, Oracle, в зависимости от настроек, воспримет это либо как два разных запроса, либо как один.

Да. Вот только в некоторых случаях настройка "как один" не всегда дает хорошие результаты...
Причём фишка распознавания похожих запросов в нормальных системах абсолютно не востребована. Это будет запрос в одном методе в одном месте программы. Главное передавать параметры параметрами, а не конкантенацией и всё получится.
13 июн 12, 12:54    [12707032]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54517
Блог
Алексей К
Причём фишка распознавания похожих запросов в нормальных системах абсолютно не востребована. Это будет запрос в одном методе в одном месте программы. Главное передавать параметры параметрами, а не конкантенацией и всё получится.

Ну, "на самом деле" одни параметры стоит передавать параметрами, а другие - конкатенацией. Это с точки зрения оптимальной производительности. Но в любом случае я не вижу разницы между вопросами "умеет ли некий SQL-фреймворк использовать параметры" и "умеет ли некий ORM использовать параметры", всё равно главный вопрос - "умеет ли программист этим пользоваться".
13 июн 12, 12:59    [12707067]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
softwarer
Ну, "на самом деле" одни параметры стоит передавать параметрами, а другие - конкатенацией. Это с точки зрения оптимальной производительности.
Согласен. Но это скорее от безысходности. Вечная проблема передачи массива, с целью выполнить запрос вида ... where Value in (1,2,3,4,5)
softwarer
Но в любом случае я не вижу разницы между вопросами "умеет ли некий SQL-фреймворк использовать параметры" и "умеет ли некий ORM использовать параметры", всё равно главный вопрос - "умеет ли программист этим пользоваться".
Это да.
13 июн 12, 13:05    [12707102]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54517
Блог
Алексей К
Согласен. Но это скорее от безысходности.

Да нет, именно производительности. То, о чём упоминал коллега Сфинкс - объединение в один план не всегда благо.

Алексей К
Вечная проблема передачи массива, с целью выполнить запрос вида ... where Value in (1,2,3,4,5)

Не вижу в этом проблемы, признаться. Меня вполне устраивает генерить where value in (?,?,?,?,?), но если это начинает напрягать, по крайней мере в Оракле можно передать табличный параметр.
13 июн 12, 13:11    [12707153]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
softwarer
Алексей К
Согласен. Но это скорее от безысходности.

Да нет, именно производительности. То, о чём упоминал коллега Сфинкс - объединение в один план не всегда благо.
Замена параметра константой - какой-то эксклюзивный случай. В MSSQL ни разу не помогало.
softwarer
Алексей К
Вечная проблема передачи массива, с целью выполнить запрос вида ... where Value in (1,2,3,4,5)

Не вижу в этом проблемы, признаться. Меня вполне устраивает генерить where value in (?,?,?,?,?),
Всё несколько сложнее, если массив имеет переменную длину с размером до, например, 100+ элементов. Впрочем, способ действительно интересный, ранее его не встречал.
softwarer
но если это начинает напрягать, по крайней мере в Оракле можно передать табличный параметр.
К сожалению, прошлые версии MSSQL такого не умеют. Можно поизвращаться через всякие парсеры строки в временную таблицу, но конкантенция чаше проще.
13 июн 12, 13:20    [12707217]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54517
Блог
Алексей К
Замена параметра константой - какой-то эксклюзивный случай. В MSSQL ни разу не помогало.

Это да. Поскольку оптимизатор MSSQL меняет обратно на параметр, это его фишка

Алексей К
Всё несколько сложнее, если массив имеет переменную длину с размером до, например, 100+ элементов.

Теоретически это проблема, типа замусоривания кэша ста одинаковыми планами. На практике же получается так: во-первых, пользователи редко выбирают много элементов (а такие запросы в 99% случаев переменного числа параметров - пользовательский фильтр по чеклисту или типа того), а во-вторых, когда пользователь создаёт "необычный" запрос, ему как правило стоит сделать и "эксклюзивный" план. Так что в результате подход оказывается довольно неплох по цена/качество.
13 июн 12, 13:23    [12707254]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
softwarer
Алексей К
Замена параметра константой - какой-то эксклюзивный случай. В MSSQL ни разу не помогало.

Это да. Поскольку оптимизатор MSSQL меняет обратно на параметр, это его фишка
Хммм... Вроде читал что это не так. Ну да ладно, уточню потом.
softwarer
Теоретически это проблема, типа замусоривания кэша ста одинаковыми планами. На практике же получается так: во-первых, пользователи редко выбирают много элементов (а такие запросы в 99% случаев переменного числа параметров - пользовательский фильтр по чеклисту или типа того), а во-вторых, когда пользователь создаёт "необычный" запрос, ему как правило стоит сделать и "эксклюзивный" план. Так что в результате подход оказывается довольно неплох по цена/качество.
+ план выполнения с where Value in(1,2,3) часто гораздо эффективнее чем where Value in(select ...)
13 июн 12, 13:28    [12707305]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54517
Блог
Алексей К
Хммм... Вроде читал что это не так. Ну да ладно, уточню потом.

Я в своё время поучаствовал в очень масштабной буче на эту тему, в итоге два крупных и известных в наших интернетах мсскл-щика долго между собой спорили и в итоге пришли к выводу, что таки так. Новой информации пока не поступало.
13 июн 12, 13:36    [12707379]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
softwarer
Алексей К
Хммм... Вроде читал что это не так. Ну да ладно, уточню потом.

Я в своё время поучаствовал в очень масштабной буче на эту тему, в итоге два крупных и известных в наших интернетах мсскл-щика долго между собой спорили и в итоге пришли к выводу, что таки так. Новой информации пока не поступало.
Ок
13 июн 12, 13:37    [12707390]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
_Case
Member

Откуда:
Сообщений: 145
zeehond

на сервере очень быстро образуется нечто типа
myProcedure
myProcedure1
myProcedureOld
myProcedure2008
myProcedureForThatSpecificCaseOnlySphinxMvKnowsAbout
и так далее

а внутри них - ужасная каша из нечитаемой копипасты
подобная тому примеру, который я привёл чуть выше

SQL - не тот язык, на котором можно что-то серьёзное и большое писать и без приложения нечеловеческих усилий поддерживать
в нём нет ни внутренней, ни внешней дисциплины


Мне кажется, виноват в подобном беспорядке, приведенном выше, не язык SQL и не сервер СУБД, а плохая организация, отсутствие порядка в самом проекте.. Если на DEV или Production DB сервере аккуратно следить за API (хранимыми процедурами, функциями) своевременно обновлять и удалять неиспользуемые устаревшие процедуры, давать нормальные имена процедурам (т.е. чтобы из имени процедуры было полностью ясно что она делает), хранить всё в системе контроля версий, то такие проблемы возникать не будут..

Подобный бардак ведь может иметь место и для Java/C# кода, если некоторые программисты, к примеру будут называть методы в классе как:

MyMethod1();
MyNewMethod1();
MyMethod2();

- часть из которых уже устарела и неиспользуется.. Или будут "плодить" классы с названиями:

DataMapper1
NewDataMapper
ReallyNewMapper

и не "подчищать" устаревшие/неиспользуемые классы.. Это IMHO проблема в том, что бардак на проекте, а не в языке разработки..

Ведь, насколько я знаю, сейчас продолжают ещё использовать язык С для разработки коммерческих приложений, а там в плане архитектуры аналогичная ситуация - плоский набор функций, а в СУБД - плоский набор процедур, и разработчики на С не страдают от этого факта - используют например префиксы в наименовании функций, чтобы разделить на группы функциональность..
Как например, в библиотеке графики OpenGL:

glBegin();
glEnd();
...
13 июн 12, 14:35    [12707898]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54517
Блог
_Case
Мне кажется, виноват в подобном беспорядке, приведенном выше, не язык SQL и не сервер СУБД, а плохая организация, отсутствие порядка в самом проекте..

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

Если коллега zeehond наблюдает такой бардак исключительно в SQL-части приложений, это всего лишь показывает, что работающий с ним коллектив работает с "другими инструментами" гораздо лучше, а SQL использует как свалку. Что в общем и до того изрядно подозревалось.
13 июн 12, 14:48    [12707991]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
_Case
используют например префиксы в наименовании функций
В итоге получается, что проще не разделять метод на методы. Результат мы видим.

Ещё есть методика - parameter object. С этим даже в продвинутом PL/SQL туго.

Это из наболевшего. :-)
13 июн 12, 14:52    [12708036]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 2935
softwarer,

для жабки есть куча инструментария для выявления потенциальных проблем и слежением за codestyle, к примеру:
http://pmd.sourceforge.net/pmd-5.0.0/
http://checkstyle.sourceforge.net/

нужно их (проверки) просто принудительно в сборку включать и фарша в коде не будет
13 июн 12, 14:53    [12708041]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
Алексей К
Ещё есть методика - parameter object. С этим даже в продвинутом PL/SQL туго
Хотя нет, в PL/SQL вроде с этим всё в порядке. :-)
13 июн 12, 15:02    [12708131]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 19 20 [21] 22 23   вперед  Ctrl
Все форумы / Работа Ответить