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

Откуда: Киев
Сообщений: 1022
автор
вот тут просто мегаотличный пример SQL-делирия
http://www.sql.ru/forum/actualthread.aspx?bid=6&tid=947786&pg=-1

и с таким ведь приходится регулярно сталкиваться, когда приходится написанное хардкорными базистами переписывать по-нормальному


Ага-ага. Прблема этой штуки только в том, что она медленно работает, не более. Только вот откуда уверенность, что Ваш JAVA-овский код перегрызет подобное быстрее?
13 июн 12, 01:21    [12705225]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
zeehond
Member [заблокирован]

Откуда:
Сообщений: 2535
sphinx_mv
Алексей К
Просто текст SQL будет храниться не в SP/View. Вот и вся разница.

1) динамический SQL на сервере - вместо того, чтобы ОДИН раз просчитать план выполнения запроса сервер имеет почти 100% шанс "расковыривать" КАЖДЫЙ обрабатываемый запрос... Чем это грозит для производительности - домашнее задание.


глупость!
все запросы, сгенерированные ORM, выполняются как prepared statement
соответственно все запросы одного и того же типа будут выполняться по одному и тому же плану а не ad hoc

sphinx_mv
4) изменения в схеме данных на сервере - не ловятся.

глупость!
-Dhibernate.ddl.auto=validate и всё ловится

sphinx_mv
5) модификация запросов (чудом оптимизированных) -> перекомпиляция проекта.


и что в этом плохого?
с использованием jrebel это занимает пару секунд
(а запросы вы лучше головой оптимизируйте, а то чудо распухнет и будет мешать ходить)

sphinx_mv
6) sql-инъекции.

глупость!
это отсекается даже не на уровне ORM, а на уровне драйвера базы данных

итого:
речь пациента чуть менее чем наполовину состоит из глупости, остальное - невнятный бред
13 июн 12, 01:23    [12705228]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
zeehond
Member [заблокирован]

Откуда:
Сообщений: 2535
londinium
автор
вот тут просто мегаотличный пример SQL-делирия
http://www.sql.ru/forum/actualthread.aspx?bid=6&tid=947786&pg=-1

и с таким ведь приходится регулярно сталкиваться, когда приходится написанное хардкорными базистами переписывать по-нормальному


Ага-ага. Прблема этой штуки только в том, что она медленно работает, не более. Только вот откуда уверенность, что Ваш JAVA-овский код перегрызет подобное быстрее?


а проблема базистов в том, что единственной проблемой SQL-вермишели они считают то, что она "медленно работает, не более"

что касается чисто производительности - при правильно спроектированной архитектуре системы "явовский код" изрядную часть данных вытащит не из базы а из кэша - локальной или сетевой памяти
поэтому запрос к базе будет существенно легче

ну а про остальное я уже 65535 раз написал выше, не буду повторяться
13 июн 12, 01:29    [12705238]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
londinium
Member

Откуда: Киев
Сообщений: 1022
автор
при правильно спроектированной архитектуре системы "явовский код" изрядную часть данных вытащит не из базы а из кэша - локальной или сетевой памяти

Да-да-да. Видел я такую систему, все как Вы любите, - сервер приложений, открытый курсор и прочее. Результат простой - захлебывающийся Informix
13 июн 12, 01:33    [12705246]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13630
sphinx_mv
1) динамический SQL на сервере - вместо того, чтобы ОДИН раз просчитать план выполнения запроса сервер имеет почти 100% шанс "расковыривать" КАЖДЫЙ обрабатываемый запрос... Чем это грозит для производительности - домашнее задание.
Планы выполнения динамических запросов с параметрами в твоей БД не кэшируются? Жаль.
sphinx_mv
2) про оптимизацию запросов, которые "внезапно" стали медленно работать, можно забыть - то есть, совсем...
3) качество написания запросов у разработчиков которые SQL видели только на картинке и не имеют ни малейшего представления ни о планах запросов, ни о трассировке и т.п. - не менее "положительный" эффект...
Только чистые СУБДисты умеют смотреть планы выполнения запросов и мутить индексы. Ага.
sphinx_mv
4) изменения в схеме данных на сервере - не ловятся.
5) модификация запросов (чудом оптимизированных) -> перекомпиляция проекта.
Кодогенерируется линковый датаконтекст по БД. В результате перекомпиляции проекта вылазят все нестыковки. К вопросу о зачем нужна компиляция проекта.
sphinx_mv
6) sql-инъекции.
Опять мимо.
sphinx_mv
7) "Барабашки" на сервере баз данных (внезапные кратковременные тормоза и прочее) в следствии неоднозначности запросов и планов их выполнения.
и т.д... и т.д... и т.д...
"Разруха, она в головах" (с)
sphinx_mv
Про разграничения прав доступа на схему данных на сервере - это вообще отдельная история.
Рассказывай. Внимательно слушаем.
13 июн 12, 06:06    [12705361]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
gyrus
Member

Откуда:
Сообщений: 13923
Алексей К
sphinx_mv
Про разграничения прав доступа на схему данных на сервере - это вообще отдельная история.
Рассказывай. Внимательно слушаем.

Ща расскажет! Можно я тоже послушаю?!

Я конечнео еще рассчитываю услышать о том, какие я ему рекомедации давал... Ну и по мелочи... вроде того какие же проблемы могут возникнуть из-за "отдельный JRE "на каждый отдельный JAVA-писаный"", особенно если вспомнить " про возникающие проблемы с конфликтами версий (даже при таких "инсталяциях"), настроек, путей и прочего"... я бы охотно послушал мнение "специалиста" :)
13 июн 12, 10:38    [12706039]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
gyrus
Member

Откуда:
Сообщений: 13923
Андрей Панфилов
zeehond
у него многомиллионная installed base - а это гарантия качества, 100500 леммингов все критические баги найдут чисто статистически достаточно быстро
Из этих мульенов нужно срезать тех, которые используют JBoss исключительно как Servlet Container (там же tomcat внутри?) и огромная installed base резко поредеет

Давайте уточним две вещи:
1) какая часть "installed base" Websphere и WebLogic также использует эти продукты как Servlet Container - надо полагать, вы обладаете какой-то тайной статистикой на сей счет, вы уж поделитесь... а то как-то неловко получается
3) Какой именно Servlet Container используется "внутри"Websphere и WebLogic?

Андрей Панфилов
(кстати, RedHat собирается нормальные скрипты для JBoss написать (по типу такого: https://docs.google.com/a/panfilov.tel/file/d/0B1wMeUJtPKj7d1RQd2dFQzY2aGs/edit?pli=1) или нужно nohup run.sh & колхозить?).

Кстати существует множесто способов управлять JBoss AS - добавление одного или двух возможно кому-то доставит больше комфорта(а кого-то будет сильно раздражать, как меня раздражают подобные способы управления IBM Websphere, впрочем и для Websphere таких способов тоже существует более одного) , но никак не более того...
13 июн 12, 10:47    [12706101]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
Алексей К
sphinx_mv
1) динамический SQL на сервере - вместо того, чтобы ОДИН раз просчитать план выполнения запроса сервер имеет почти 100% шанс "расковыривать" КАЖДЫЙ обрабатываемый запрос... Чем это грозит для производительности - домашнее задание.
Планы выполнения динамических запросов с параметрами в твоей БД не кэшируются? Жаль.

Перед тем как закэшировать план, не мешало бы обеспечить его разбор...
Вопрос, только в том, как закэшированные планы запросов помогут, если запросы "по факту" не одинаковы...
Запрос 1
select * FROM TBL WHERE FLD = 'всякая фигня 1'

Запрос 2
SELECT * from TBL where FLD = 'всякая фигня 1'

Запрос 3
select* FRom TBL where fld = 'всякая фигня 2'

Запрос 4
SELECT * From tbl where FLD = 'всякая фигня 2'

Это одинаковые запросы? А вот и НЕТ! (даже если и по-парно) Они просто ПОХОЖИ...
А планы у них одинаковы? Возможно, но очень не факт...
Для РАЗНЫХ запросов необходимо компилировать свой СОБСТВЕННЫЙ план...
Итого, четыре РАЗНЫХ запроса, каждый со своим собственным планом... Толку от кэширования?
Ресурсы,.. ресурсы... ресурсы... И вопросы... вопросы... вопросы "почему сервер БД так медленно работает?"
А потому и медленно работает, что "не умеете готовить"... И продолжайте надеяться, что prepaire перед выполнением Вас спасет...
Алексей К
sphinx_mv
2) про оптимизацию запросов, которые "внезапно" стали медленно работать, можно забыть - то есть, совсем...
3) качество написания запросов у разработчиков которые SQL видели только на картинке и не имеют ни малейшего представления ни о планах запросов, ни о трассировке и т.п. - не менее "положительный" эффект...
Только чистые СУБДисты умеют смотреть планы выполнения запросов и мутить индексы. Ага.

"Идеальный план" - далеко не факт, что это "лучший план"...
И даже индексы мутить налево и направо при "полмульёне" запросов, которые лежат, хрен знает где, и вызаваются, фиг знает когда, НЕ ПОМОЖЕТ... Но производительность это гарантированно посадит...

Кстатии, что там на тему трассировки?
Судя по всему, ничего... Собственно, задокументировано...
Алексей К
sphinx_mv
4) изменения в схеме данных на сервере - не ловятся.
5) модификация запросов (чудом оптимизированных) -> перекомпиляция проекта.
Кодогенерируется линковый датаконтекст по БД. В результате перекомпиляции проекта вылазят все нестыковки. К вопросу о зачем нужна компиляция проекта.

А при перелинковке поехали другие нестыковки...А потом еще куча ранее невыявленных багов после перелинковки повылазила... И так далее и тому подобное...
Ну, а про 100% гарантии функционирования всех, разбросанных по разным частям проекта запросов - это сказки из другой реальности...
Алексей К
sphinx_mv
6) sql-инъекции.
Опять мимо.

Да, что Вы говорите!
А то, что sql-инъекции часто прямое следствие не очень (а иногда даже и очень) правильного использования динамических запросов, Вы в курсе?
Алексей К
sphinx_mv
7) "Барабашки" на сервере баз данных (внезапные кратковременные тормоза и прочее) в следствии неоднозначности запросов и планов их выполнения.
и т.д... и т.д... и т.д...
"Разруха, она в головах" (с)

Не просто в головах, а в конкретных головах, которые НЕ УМЕЮТ пользоваться средствамим SQL-сервера, предполагая, что у них "получится лучше"... Только почему-то получается как всегда - с хреновой производительностью и офигенным потреблением ресурсов... "SQL на клиенте"... Запросы к "живым" таблицам...

Говорите, что знаете ООП?
Утверждаете, что ООП предполагает ограничение доступа к внутренним данным и сокрытие реализации методов?
И кто Вам мешает это же самое обеспечивать через вызов хранимых процедур и функций непосредственно с сервера базы данных, который, к тому же, справится с этим гораздо лучше и прозрачнее?
Алексей К
sphinx_mv
Про разграничения прав доступа на схему данных на сервере - это вообще отдельная история.
Рассказывай. Внимательно слушаем.

А Вам это зачем?
У Вас же собственная "самая крутая" система раздачи прав, n'est pas?
13 июн 12, 11:05    [12706247]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13630
sphinx_mv
Алексей К
пропущено...
Планы выполнения динамических запросов с параметрами в твоей БД не кэшируются? Жаль.

Перед тем как закэшировать план, не мешало бы обеспечить его разбор...
Вопрос, только в том, как закэшированные планы запросов помогут, если запросы "по факту" не одинаковы...
Запрос 1
select * FROM TBL WHERE FLD = 'всякая фигня 1'

Запрос 2
SELECT * from TBL where FLD = 'всякая фигня 1'

Запрос 3
select* FRom TBL where fld = 'всякая фигня 2'

Запрос 4
SELECT * From tbl where FLD = 'всякая фигня 2'

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

А так?
exec sp_executesql 'SELECT * From tbl where FLD = @p1', '@p1 varchar(100)', @p1 = 'всякая фигня 1'
exec sp_executesql 'SELECT * From tbl where FLD = @p1', '@p1 varchar(100)', @p1 = 'всякая фигня 2'
exec sp_executesql 'SELECT * From tbl where FLD = @p1', '@p1 varchar(100)', @p1 = 'всякая фигня 3'
exec sp_executesql 'SELECT * From tbl where FLD = @p1', '@p1 varchar(100)', @p1 = 'всякая фигня 4'
13 июн 12, 11:17    [12706354]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
DeathHand
Member

Откуда: Мск>СПБ>Врн
Сообщений: 2705
sphinx_mv
Вопрос, только в том, как закэшированные планы запросов помогут, если запросы "по факту" не одинаковы...

А никак. У нас попадание в кеш на оракл 10 с прикрученными уйбирнейтами - 40-60% (!!!)

И как не талдычишь горячим парням - что нужен бинд, парни, пишите процедурами чтоли! Не пробивает никак вообще.
13 июн 12, 11:19    [12706367]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
DeathHand
Member

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

Не знаю как, но прилетает строчкой. Без биндов.
13 июн 12, 11:21    [12706387]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13630
DeathHand
Алексей К
А так?

Не знаю как, но прилетает строчкой. Без биндов.
Главное план выполнения select-а кэшируется для разных параметров. Впрочем, вам ораклистам не понять, у вас там всё через ж@пу. :-)
13 июн 12, 11:24    [12706409]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
DeathHand
Member

Откуда: Мск>СПБ>Врн
Сообщений: 2705
Алексей К
план выполнения select-а кэшируется для разных параметров

А должна лежать "рыба" с биндами. Тогда ненужно будет заново вычислять план, а это немалая работа на сервер.
Алексей К
у вас там всё через ж@пу

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

Откуда: Новосибирск
Сообщений: 13630
DeathHand
Алексей К
план выполнения select-а кэшируется для разных параметров

А должна лежать "рыба" с биндами. Тогда ненужно будет заново вычислять план, а это немалая работа на сервер.
Какая рыба, ты о чём? Там тупо хэштаблица "строка SQL" => "план выполнения". Но я это про MSSQL. Проблемы ораклов меня не интересуют.
DeathHand
Алексей К
у вас там всё через ж@пу

У нас, как раз, все четко и обкатано десятилетиями.
Аутотренинг?
13 июн 12, 11:30    [12706444]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
zeehond
Member [заблокирован]

Откуда:
Сообщений: 2535
sphinx_mv
Говорите, что знаете ООП?
Утверждаете, что ООП предполагает ограничение доступа к внутренним данным и сокрытие реализации методов?


о, новое слово в компьютер сайенсе
ООП в применении не только к ассемблеру, но и к SQL - на примере хранимых процедур
cool!
к вашему сведению, уважаемый пациент, ООП это не только (и не столько) сокрытие реализации и ограничение доступа
это прежде всего полиморфизм и наследование

sphinx_mv
И кто Вам мешает это же самое обеспечивать через вызов хранимых процедур и функций непосредственно с сервера базы данных, который, к тому же, справится с этим гораздо лучше и прозрачнее?


мешает - та самая чудовищная вермишель, которая внутри этих самых хранимых процедур и функций со временем образуется
а так как новый запрос =! перекомпиляция проекта, чем вы тут недавно гордились
то на сервере очень быстро образуется нечто типа
myProcedure
myProcedure1
myProcedureOld
myProcedure2008
myProcedureForThatSpecificCaseOnlySphinxMvKnowsAbout
и так далее

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

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

Откуда: Новосибирск
Сообщений: 13630
zeehond
sphinx_mv
Говорите, что знаете ООП?
Утверждаете, что ООП предполагает ограничение доступа к внутренним данным и сокрытие реализации методов?


о, новое слово в компьютер сайенсе
ООП в применении не только к ассемблеру, но и к SQL - на примере хранимых процедур
cool!
к вашему сведению, уважаемый пациент, ООП это не только (и не столько) сокрытие реализации и ограничение доступа
это прежде всего полиморфизм и наследование
Более того, пациент даже не знает, что в его любимом SQL тоже можно применять принцип наследования, используя select * from XXX.
13 июн 12, 11:40    [12706525]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
zeehond
Member [заблокирован]

Откуда:
Сообщений: 2535
Алексей К
sphinx_mv
пропущено...

Перед тем как закэшировать план, не мешало бы обеспечить его разбор...
Вопрос, только в том, как закэшированные планы запросов помогут, если запросы "по факту" не одинаковы...
Запрос 1
select * FROM TBL WHERE FLD = 'всякая фигня 1'

Запрос 2
SELECT * from TBL where FLD = 'всякая фигня 1'

Запрос 3
select* FRom TBL where fld = 'всякая фигня 2'

Запрос 4
SELECT * From tbl where FLD = 'всякая фигня 2'

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

А так?
exec sp_executesql 'SELECT * From tbl where FLD = @p1', '@p1 varchar(100)', @p1 = 'всякая фигня 1'
exec sp_executesql 'SELECT * From tbl where FLD = @p1', '@p1 varchar(100)', @p1 = 'всякая фигня 2'
exec sp_executesql 'SELECT * From tbl where FLD = @p1', '@p1 varchar(100)', @p1 = 'всякая фигня 3'
exec sp_executesql 'SELECT * From tbl where FLD = @p1', '@p1 varchar(100)', @p1 = 'всякая фигня 4'


какие-то стрёмные костыли

на уровне обращения к базе SQL, хоть через ORM хоть на голом JDBC, при использовании prepared statement всегда будет выглядеть как
"SELECT * From tbl where FLD = ?"
и именно по этой строке вменяемый сервер будет искать кэшированный план

вот тут даже и статья про это

автор
Statement Caches

Databases are tuned to do statement caches. They usually include some kind of statement cache. This cache uses the statement itself as a key and the access plan is stored in the cache with the corresponding statement. This allows the database engine to reuse the plans for statements that have been executed previously. For example, if we sent the database a statement such as "select a,b from t where c = 2", then the computed access plan is cached. If we send the same statement later, the database can reuse the previous access plan, thus saving us CPU power.

Note however, that the entire statement is the key. For example, if we later sent the statement "select a,b from t where c = 3", it would not find an access plan. This is because the "c=3" is different from the cached plan "c=2". So, for example:

For(int I = 0; I < 1000; ++I)
{
PreparedStatement ps = conn.prepareStatement("select a,b from t where c = " + I);
ResultSet rs = Ps.executeQuery();
Rs.close();
Ps.close();
}

Here the cache won't be used. Each iteration of the loop sends a different SQL statement to the database. A new access plan is computed for each iteration and we're basically throwing CPU cycles away using this approach. However, look at the next snippet:

PreparedStatement ps = conn.prepareStatement("select a,b from t where c = ?");
For(int I = 0; I < 1000; ++I)
{
ps.setInt(1, I);
ResultSet rs = ps.executeQuery();
Rs.close();
}
ps.close();

Here it will be much more efficient. The statement sent to the database is parameterized using the '?' marker in the sql. This means every iteration is sending the same statement to the database with different parameters for the "c=?" part. This allows the database to reuse the access plans for the statement and makes the program execute more efficiently inside the database. This basically let's your application run faster or makes more CPU available to users of the database.


статье между прочим 12 лет, а sphinx_mv настолько ушёл в эмуляцию ООП на SQL, что до сих пор не в курсе
и продолжает писать глупости

на планете осталось очень мало ретардов, которые при наличии prepared statement используют inline SQL parameters
это и с точки зрения реюзабельности планов выполнения плохо, и с точки зрения SQL injection
13 июн 12, 11:42    [12706545]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
AlexeiK
Member

Откуда:
Сообщений: 2830
Народ, ну так, я смотрю, что появились не довольные в том, как задан вопрос в этой теме.
И причислили это к личной обиде.
Обида заключается в том, что SQL не считаю за основной инструмент, и одновременно считая .net & java за плохой инструмент, deathhand развел флудерастию основанную на своих эмоциях.

Печально.
13 июн 12, 11:43    [12706550]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
DeathHand
Member

Откуда: Мск>СПБ>Врн
Сообщений: 2705
Алексей К
Какая рыба, ты о чём? Там тупо хэштаблица "строка SQL" => "план выполнения".

Хреновато у Вас, у мелкомягких.

К сообщению приложен файл. Размер - 34Kb
13 июн 12, 11:44    [12706561]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13630
zeehond
какие-то стрёмные костыли

на уровне обращения к базе SQL, хоть через ORM хоть на голом JDBC, при использовании prepared statement всегда будет выглядеть как
"SELECT * From tbl where FLD = ?"
и именно по этой строке вменяемый сервер будет искать кэшированный план

вот тут даже и статья про это
Какие костыли? Причём тут вообще Java? Я тебе показал какие запросы генерируют дотнетные ОРМы под MSSQL.
13 июн 12, 11:46    [12706569]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13630
DeathHand
Алексей К
Какая рыба, ты о чём? Там тупо хэштаблица "строка SQL" => "план выполнения".

Хреновато у Вас, у мелкомягких.
Почему?
13 июн 12, 11:47    [12706583]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
zeehond
Member [заблокирован]

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


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

Откуда:
Сообщений: 1672
zeehond
sphinx_mv
пропущено...

1) динамический SQL на сервере - вместо того, чтобы ОДИН раз просчитать план выполнения запроса сервер имеет почти 100% шанс "расковыривать" КАЖДЫЙ обрабатываемый запрос... Чем это грозит для производительности - домашнее задание.


глупость!
все запросы, сгенерированные ORM, выполняются как prepared statement
соответственно все запросы одного и того же типа будут выполняться по одному и тому же плану а не ad hoc

Я очень надеюсь, что в ВО ВСЕХ запросах Вы используете параметры, а не конкатенацию строк...
И ВСЕ запросы (с одинаковым набором выбираемых полей, таблиц, соединений и условий) написаны в одинаковом стиле, учитывая пробелы и регистр написания - иначе смысла в prepaired statement нет практически никакого.
Даже один-единственный, но часто вызываемый с разными условиями запрос, или запросы, отличающиеся стилями написания, могут положить всю систему.

Кстати... "Prepeired" означает всего лишь, что запрос МОЖЕТ быть выполнен, и совершенно не гарантирует того, что план запроса, который был в результате получен, будет применен для другого такого же (или похожего) запроса... Кэш на сервере - он не бездонный...
zeehond
sphinx_mv
4) изменения в схеме данных на сервере - не ловятся.

глупость!
-Dhibernate.ddl.auto=validate и всё ловится

Глупость - полностью доверять автомату...
Особенно в плане того, что некотрые изменения могут касаться и разделения объектов БД, и переносу объектов БД в другие схемы(по разным причинам!), в том числе даже на другие сервера БД... И ловить эти изменения "автоматически" - весьма смешно.

Ну, а если грузить в приложение ВСЮ схему данных - это уже даже не глупость. Это идиотизм...
zeehond
sphinx_mv
5) модификация запросов (чудом оптимизированных) -> перекомпиляция проекта.


и что в этом плохого?
с использованием jrebel это занимает пару секунд
(а запросы вы лучше головой оптимизируйте, а то чудо распухнет и будет мешать ходить)

Вам мешало? Теперь нет? Может, Вам теперь в танцоры податься? Или в Папскую капеллу?
zeehond
sphinx_mv
6) sql-инъекции.

глупость!
это отсекается даже не на уровне ORM, а на уровне драйвера базы данных

Таки то, что Вам удалили, чтобы не мешало ходить, думало лучше...
Драйверу БД совершенно ПОФИГ, какой запрос посылать из приложения на SQL-сервер - то есть КАТЕГОРИЧЕСКИ пофиг!
И совершенно точно, что никаким анализом на SQL-инъекции для этих запросов он точно НЕ занимается - иначе бы подобной уязвимости не существовало...
zeehond
итого:
речь пациента чуть менее чем наполовину состоит из глупости, остальное - невнятный бред

Шли бы Вы проспаться. А потом в библиотеку учится и учиться... Иначе с такими познаниями в базах данных и написании клиентских приложений, работающих с данными, Вы, ну, очень много наваяете "хороших" проектов... Я бы даже сказал "замечательных" проектов...
13 июн 12, 11:50    [12706606]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13630
Алексей К
zeehond
какие-то стрёмные костыли

на уровне обращения к базе SQL, хоть через ORM хоть на голом JDBC, при использовании prepared statement всегда будет выглядеть как
"SELECT * From tbl where FLD = ?"
и именно по этой строке вменяемый сервер будет искать кэшированный план

вот тут даже и статья про это
Какие костыли? Причём тут вообще Java? Я тебе показал какие запросы генерируют дотнетные ОРМы под MSSQL.
В C# будет написано что-то вроде:
string GetValueByID(int id)
{
    using(var db = DbContextFactory.GetContext())
    {
        var q = 
            from t in db.MyTable
            where t.ID == id
            select t.Value;

        return q.First();
    }
}
13 июн 12, 11:50    [12706609]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
DeathHand
Member

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

Хреновато у Вас, у мелкомягких.
Почему?

Ну, если это все, что у Вас есть для оптимизации относительно плана - то не айс :)
13 июн 12, 11:51    [12706612]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 19 [20] 21 22 23   вперед  Ctrl
Все форумы / Работа Ответить