Здравствуйте, Sinclair, Вы писали:

S>Смысл в том, что явное указание параметров точно говорит движку, какие части запроса имеют тенденцию измениться при следующем запуске. Если их нет, то для парсера весь запрос — это просто строка. Вот простейший пример:

Не думал о столь интересном примере — но в целом именно то, что я имел в виду.

Получив такой запрос, сервер сможет принять в общем случае более грамотное решение, нежели клиент, и принять его эффективнее. Почему грамотное — понятно, у сервера есть куча дополнительной информации. Почему эффективнее — потому что ему доступно все то же, что и клиенту, и еще много того, чего у клиента нет.

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

Если то же делать на сервере — прежде всего, сервер сможет эффективно определить, что он это уже делал в рамках такого же запроса с другого клиента. Если эта проверка не прошла — сервер все равно должен делать парсинг, то есть никаких дополнительных расходов. И дальше — если нужно, он может начать думать, какой из приведенных Вами вариантов лучше, причем думать, основываясь на информации (например — детерминированы ли указанные функции).

Здравствуйте, Softwarer, Вы писали:

S>Получив такой запрос, сервер сможет принять в общем случае более грамотное решение, нежели клиент, и принять его эффективнее. Почему грамотное — понятно, у сервера есть куча дополнительной информации. Почему эффективнее — потому что ему доступно все то же, что и клиенту, и еще много того, чего у клиента нет.

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

S>Клиент, получив указанный запрос, может либо прямо передать его на сервер, либо передать, как-то обработав (в частности, обернув в хранимки). Если у клиента есть выбор — ему придется, например, отпарсить запрос, определить, есть ли в нем параметры, и далее либо передать текст, либо сформировать вызов хранимок. Стоит отметить, что даже в рамках многократного повторения запроса в сеансе — клиенту потребуется либо держать собственный кэш запросов, либо многократно выполнять эту операцию (я не имею в виду вариант, когда клиент может сохранять хандл запроса).

Никакого парсера и кэша на клиенте нет и быть не может. Клиентский механизм доступа — это всего лишь промежуточное звено. Если говорить в контексте работы с дельфи, то маркеры параметров преобразуються в объекты коллеции Parameters ADO, потом идет мапирование этих объектов в интерфейсы OLEDB, которое в конечном итоге и оформляет вызов sp_executesql с необходимыми параметрами.

S>Если то же делать на сервере — прежде всего, сервер сможет эффективно определить, что он это уже делал в рамках такого же запроса с другого клиента. Если эта проверка не прошла — сервер все равно должен делать парсинг, то есть никаких дополнительных расходов. И дальше — если нужно, он может начать думать, какой из приведенных Вами вариантов лучше, причем думать, основываясь на информации (например — детерминированы ли указанные функции).

Опять же, не всегда сервер это может определить. Именно для этого и существует набор системных хранимок, реализующих модель prepare\execute — т.е. гарантированное повторное использование планов выполнения.

Здравствуйте, Softwarer, Вы писали:

S>Получив такой запрос, сервер сможет принять в общем случае более грамотное решение, нежели клиент, и принять его эффективнее. Почему грамотное — понятно, у сервера есть куча дополнительной информации. Почему эффективнее — потому что ему доступно все то же, что и клиенту, и еще много того, чего у клиента нет.
Я пока не вижу никаких способов для сервера принять "более грамотное рещение". Можно на пальцах объяснить "ход мысли алгоритма"?
S>Клиент, получив указанный запрос, может либо прямо передать его на сервер, либо передать, как-то обработав (в частности, обернув в хранимки).
Гм. Клиент вообще-то не "получает", а "порождает" запросы. На то он и клиент.
S>Если у клиента есть выбор — ему придется, например, отпарсить запрос, определить, есть ли в нем параметры, и далее либо передать текст, либо сформировать вызов хранимок. Стоит отметить, что даже в рамках многократного повторения запроса в сеансе — клиенту потребуется либо держать собственный кэш запросов, либо многократно выполнять эту операцию (я не имею в виду вариант, когда клиент может сохранять хандл запроса).
Я не очень понимаю, зачем клиенту держать собственный кэш запросов. Нам приходилось реализовывать такую штуку, но там речь шла о framework, или прослойке между собственно прикладным кодом и сервером, которая и отвечала за автоматическое сопоставление текста запроса и кэша.
S>Если то же делать на сервере — прежде всего, сервер сможет эффективно определить, что он это уже делал в рамках такого же запроса с другого клиента.
Гм. Основной вопрос — это смысл выражения "он это уже делал". Есть очень-очень много вариантов сопоставления двух запросов. И тут появляется тонкость: примитивный алгоритм сравнения не "поймает" запросы, к которым бы подошел один план, а умный рискует проработать дольше, чем оптимизатор при построении плана с нуля. Типичный tradeoff.
S>Если эта проверка не прошла — сервер все равно должен делать парсинг, то есть никаких дополнительных расходов. И дальше — если нужно, он может начать думать, какой из приведенных Вами вариантов лучше, причем думать, основываясь на информации (например — детерминированы ли указанные функции).
Вот тут я еще раз попрошу прокомментировать ход мыслей потенциального оптимизатора, связанных с детерминированностью этой функции, при выборе параметризуемых частей?

Здравствуйте, Sinclair, Вы писали:

S>Я пока не вижу никаких способов для сервера принять "более грамотное рещение". Можно на пальцах объяснить "ход мысли алгоритма"?

Хм. В первую очередь — я не вижу для клиента возможности сделать что-то лучше сервера.

Замечание: похоже, наметилось некоторое терминологическое непонимание. Под "клиентом" я имею в виду софт, работающий на клиентской машине и являющийся прослойкой между сервером и клиентским приложением — например, те же BDE/ADO/ODBC. Я не имею в виду, например, программиста, разрабатывающего клиентское приложение.

S>Гм. Основной вопрос — это смысл выражения "он это уже делал". Есть очень-очень много вариантов сопоставления двух запросов. И тут появляется тонкость: примитивный алгоритм сравнения не "поймает" запросы, к которым бы подошел один план, а умный рискует проработать дольше, чем оптимизатор при построении плана с нуля. Типичный tradeoff.

Безусловно. Но если разработчики сервера могут здесь выбрать оптимальный алгоритм — разработчик "клиентской прослойки" такой возможности практически лишен; он может либо "тупо передать текст SQL на сервер", либо практически обязан парсить его каждый раз, чтобы "передавать не тупо".

Это напоминает мне JDK, где Statement и PreparedStatement — разные понятия, работа с которыми существенно разнится. Но там хоть программист выбирает решение при разработке — а здесь клиент, получив текст SQL от приложения, должен выбрать, то ли посылать так, то ли организовывать подстановку параметров...

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

Детерминированность (понятие, кстати, тоже можно понимать по-разному) — определяет, насколько можно "вынести" вызов функции "наружу" относительно блока, в котором она употребляется — согласны? Недетерминированная функция в общем случае не может быть заменена "цельным параметром", как в первом из Ваших примеров — например, в вариантах

select random(1000)*field from table

select log(1000)*field from table

сервер может существенно оптимизировать второй, в то время как "клиентская прослойка" не имеет для этого информации (по крайней мере если функции — пользовательские, а не стандартные серверные).

Дальше гипотетически начинаются более интересные моменты. Если известна гистограмма распределения результатов функции — оптимизатор может ее учесть, в том числе решить "выносить функцию наружу или бессмысленно", в том числе "ставить ли план в зависимость от результата функции".

Например, если брать Ваш пример с датской функцией — сервер должен решить, будет ли он пользоваться индексом или full table scan. То есть в варианте "< @p1" сервер в принципе может вычислить p1 и на его основании выбрать тот или иной план, это, соответственно, повышает привлекательность такого варианта параметризации. С другой стороны, если такой информации нет — серверу может показаться более интересным воспользоваться планом для четвертого варианта, поскольку он потенциально "максимально кэширумый".

Здравствуйте, pkarklin, Вы писали:

P>В том то и дело, что сервер не всегда может принять грамотное решение о замене статических значений параметрами.
P>И эту часть в большинстве случаев приходиться решать или с помощью хп, или с помощью явной парамтеризации на клиенте.

Само собой. Именно поэтому вариант, когда софт не проявляет самодеятельности, мне и нравится больше остальных

P>Никакого парсера и кэша на клиенте нет и быть не может. Клиентский механизм доступа — это всего лишь промежуточное звено. Если говорить в контексте работы с дельфи, то маркеры параметров преобразуються в объекты коллеции Parameters ADO, потом идет мапирование этих объектов в интерфейсы OLEDB, которое в конечном итоге и оформляет вызов sp_executesql с необходимыми параметрами.

Для того, чтобы найти и преобразовать маркеры, уже необходим парсер, практически такой же, как и на сервере (надеюсь, мы различаем парсер и синтаксический анализатор?).

P>Опять же, не всегда сервер это может определить. Именно для этого и существует набор системных хранимок, реализующих модель prepare\execute — т.е. гарантированное повторное использование планов выполнения.

Я только не понимаю, нафига для этого хранимки, если честно. Модель prepare/execute в них совершенно не нуждается. Собственно, такое впечатление, что хранимки появились для обхода самодеятельности сервера в плане автопараметризации.

Здравствуйте, Softwarer, Вы писали:

S>Безусловно. Но если разработчики сервера могут здесь выбрать оптимальный алгоритм — разработчик "клиентской прослойки" такой возможности практически лишен; он может либо "тупо передать текст SQL на сервер", либо практически обязан парсить его каждый раз, чтобы "передавать не тупо".
Что-то тут опять какой-то мисандерстундинг наметился.
Допустим клиент пишет:

  DB.Execute("select ... where a=@a and b=@b", DB.Parameter("@a", 1), DB.Parameter("@b", 2));

Далее драйвер может передать на сервер:
1. "select .... where a=? and b=?", 1,2
либо
2. sp_execute "select .... where a=? and b=?", @a int, @b int, 1, 2
Для клиента (драйвера) затраты на реализацию обоих вариантов идентичны, разница в синтаксисе, для сервера вариант 2 предпочтительнее...

S>Это напоминает мне JDK, где Statement и PreparedStatement — разные понятия, работа с которыми существенно разнится. Но там хоть программист выбирает решение при разработке — а здесь клиент, получив текст SQL от приложения, должен выбрать, то ли посылать так, то ли организовывать подстановку параметров...
Бррр... Что значит "посылать так"? Если программист клиентского приложения указал константы, значит приедут константы, драйвер тут ничего не сделает, если же программист указал параметры, то приедут параметры, вопрос только в каком виде. При этом для драйвера это, по большей части, всего лишь вопрос синтаксиса.

Здравствуйте, Softwarer, Вы писали:

S>Здравствуйте, pkarklin, Вы писали:

S>Для того, чтобы найти и преобразовать маркеры, уже необходим парсер, практически такой же, как и на сервере (надеюсь, мы различаем парсер и синтаксический анализатор?).

Да нет же, парсер на клиенте, который заменяет :param_name (как это делают наследники TDataSet в Delphi) или ?, как это делает ODBC очень прост.

S>Я только не понимаю, нафига для этого хранимки, если честно. Модель prepare/execute в них совершенно не нуждается. Собственно, такое впечатление, что хранимки появились для обхода самодеятельности сервера в плане автопараметризации.

Модель prepare\execute была создана для Ad hoc запросов с клиента,в то время как план выполнения хп заведомо будет кэшироваться и повторно использоваться.

Здравствуйте, <Аноним>, Вы писали:
А>так чтоб в в одном случае правильно было бы юзать индекс а в другом fullscan
В таком простом случае выбора просто нет. Рассмотри пример с двумя параметрами:

select * from people where occupation = "Programmer" and Gender = @Male

и select * from peope where occupation = "Manager" and Gender=@Male

Предполагаем, что в среднем количество мужчин и женщин одинаково, программеров примерно 1%, менеджеров — 70%. Есть индексы по Occupation и по Gender.
В первом случае очевидно имеет смысл сделать index seek по Occupation, а затем bookmark lookup и filter по Gender. (дорогой фильтр применится к 1% от общего количества записей).
Во втором случае имеет смысл наоборот, сделать index seek по Gender=@male, т.к. фильтровать 50% от N выгоднее, чем 70% от N.

Здравствуйте, Softwarer, Вы писали:
S>Замечание: похоже, наметилось некоторое терминологическое непонимание. Под "клиентом" я имею в виду софт, работающий на клиентской машине и являющийся прослойкой между сервером и клиентским приложением — например, те же BDE/ADO/ODBC. Я не имею в виду, например, программиста, разрабатывающего клиентское приложение.
А-а, вот оно в чем дело. Ну, вообще-то речь вроде бы не шла об автопараметризации в этой прослойке.
S>Безусловно. Но если разработчики сервера могут здесь выбрать оптимальный алгоритм — разработчик "клиентской прослойки" такой возможности практически лишен; он может либо "тупо передать текст SQL на сервер", либо практически обязан парсить его каждый раз, чтобы "передавать не тупо".
Гм. Тут есть некоторая неясность с "парсить каждый раз". Я не очень понимаю, откуда у прослойки берется выбор. Ей уже дали параметризованный запрос. Можно, конечно, выполнить подстановку (как это делает BDE — по словам pkarklin), или добиться того, чтобы на сервер уехал запрос с уже заданными пользователем параметрами.
S>Это напоминает мне JDK, где Statement и PreparedStatement — разные понятия, работа с которыми существенно разнится. Но там хоть программист выбирает решение при разработке — а здесь клиент, получив текст SQL от приложения, должен выбрать, то ли посылать так, то ли организовывать подстановку параметров...
Где "здесь"??? Я что-то вообще нить потерял. ADO/BDE/ODBC/OLE DB ничем не отличаются от JDK. Точно также программист выбирает, что будет параметризовываться.

Здравствуйте, Merle, Вы писали:

M>Для клиента (драйвера) затраты на реализацию обоих вариантов идентичны, разница в синтаксисе, для сервера вариант 2 предпочтительнее...

Имхо идеальный вариант — когда драйвер передает на сервер информацию типа

"select .... where a=? and b=?", 1 int,2 int

Ну а дальше сервер вызывает тот модуль, который вызвал бы при приходе вызова ХП (я правильно понимаю, что это ХП?)sp_execute.

M>Бррр... Что значит "посылать так"? Если программист клиентского приложения указал константы, значит приедут константы, драйвер тут ничего не сделает, если же программист указал параметры, то приедут параметры, вопрос только в каком виде. При этом для драйвера это, по большей части, всего лишь вопрос синтаксиса.

Ээ.. следующую цитату plarklin я понял как то, что "параметры, не обернутые в вызов хранимки, не приедут никогда".

------------------------------------------------------------------------------------------------------------------
1 не будет никогда, ибо '?' — это маркер параметра для ODBC функции SQLPrepare. При этом на сервер при первом вызове будет отправлен вызов sp_prepare, где будет текст запроса и параметр вида @param. А уже затем sp_execute c параметром.
------------------------------------------------------------------------------------------------------------------

Я неправ? Как это следует понимать?

Здравствуйте, Softwarer, Вы писали:

S>Ээ.. следующую цитату plarklin я понял как то, что "параметры, не обернутые в вызов хранимки, не приедут никогда".

S>------------------------------------------------------------------------------------------------------------------
S>1 не будет никогда, ибо '?' — это маркер параметра для ODBC функции SQLPrepare. При этом на сервер при первом вызове будет отправлен вызов sp_prepare, где будет текст запроса и параметр вида @param. А уже затем sp_execute c параметром.
S>------------------------------------------------------------------------------------------------------------------

S>Я неправ? Как это следует понимать?

Правильно вы поняли. Не знает парсер сиквела что есть "?".

Здравствуйте, pkarklin, Вы писали:

P>Да нет же, парсер на клиенте, который заменяет :param_name (как это делают наследники TDataSet в Delphi) или ?, как это делает ODBC очень прост.

Тот парсер, который в наследнике TDataSet, еще и весьма глючен — что иллюстрирует последствия этой простоты.

Он действительно прост — как прост и на сервере. Но тем не менее, он работает очень долго по сравнению с поиском в кэше отпарсенного запроса. То есть вариант:

1. На сервер приехал текст SQL
2. Текст ищется в кэше
3. При отсутствии — парсится, анализируется, строится план

эффективнее, нежели

0. Текст SQL преобразовывается "простым парсером"
1. ---
2. ---
3. ---

S>>Я только не понимаю, нафига для этого хранимки, если честно. Модель prepare/execute в них совершенно не нуждается. Собственно, такое впечатление, что хранимки появились для обхода самодеятельности сервера в плане автопараметризации.
P>Модель prepare\execute была создана для Ad hoc запросов с клиента,в то время как план выполнения хп заведомо будет кэшироваться и повторно использоваться.

Модель prepare/execute, по моим представлениям, появилась раньше понятия "хранимка" Я понял Ваше утверждение так, что в MSSQL ее можно реализовать только с помощью хранимок же (sp_prepare, sp_execute). Я неправильно понял? Как оно?

Здравствуйте, Sinclair, Вы писали:

S>Гм. Тут есть некоторая неясность с "парсить каждый раз". Я не очень понимаю, откуда у прослойки берется выбор. Ей

Это растет из фразы Merle о том, что варианты с приходом "просто sql" и "sp_execute sql" различны по эффективности и сервер в общем случае не может преобразовать менее эффективный вариант в более эффективный.

Если не может — значит, клиент должен в какой-то ситуации посылать одно, в какой-то ситуации — другое, делая выбор на основании чего-то.

Здравствуйте, pkarklin, Вы писали:

P>Правильно вы поняли. Не знает парсер сиквела что есть "?".

Тогда я попросил бы Вас с Merle прийти к единому мнению по этому вопросу. Насколько я понимаю, сейчас, говоря о передаче параметризованного запроса с клиента:

— Вы говорите, что возможен только вариант с хранимкой
— Merle говорит, что вариант без хранимки возможен, но менее эффективен.

Собственно, меня удивляют оба варианта, но хотелось бы знать "как оно есть на самом деле".

Здравствуйте, Softwarer, Вы писали:


S>- Вы говорите, что возможен только вариант с хранимкой
S>- Merle говорит, что вариант без хранимки возможен, но менее эффективен.

S>Собственно, меня удивляют оба варианта, но хотелось бы знать "как оно есть на самом деле".

Давайте опять разбираться с терминологией. Хранимки реализующие модель prepare\execute ODBC (sp_prepare, sp_execute, sp_uprepare) и хранимка sp_executesql — это системные хранимки. И они на писаны не на T-SQL, в отличаи от "пользовательких" хранимок, которые пишуться на T-SQL. Т.е. эти системные хранимки предоставлены движком сиквела именно для реализации параметризированных запросов, требующих поворного использования планов выполнения.

Здравствуйте, Softwarer, Вы писали:

S>Имхо идеальный вариант — когда драйвер передает на сервер информацию типа
S>

"select .... where a=? and b=?", 1 int,2 int

И чем это отличается от подстановки вызова хранимки перед запросом? Ничем, кроме синтаксиса.

S>Ээ.. следующую цитату plarklin я понял как то, что "параметры, не обернутые в вызов хранимки, не приедут никогда".
Да, все верно, тут я немного прогнал.
На самом деле возможны два варианта вызова.
1. Prepared Queries, осуществляется в несколько этапов. Сначала передается запрос с параметрами (с теми самыми многострадальными вопросиками aka маркерами), сервер подготавливает план, не выполняя запрос и возвращает указатель на подготовленый план. На втором этапе драйвер передает вместе с указателем на план список конкретных значений.
API драйвера делает это через SQLPrepare/SQLExecute и ICommandPrepare интерфейс, API сервера через процедуры sp_prepare/sp_execute
2. Вариант с sp_executesql, здесь все делается за раз, но план в последствии может быть переиспользован, в драйвере это SQLExecDirect, на сервере sp_executesql.

Вообщем, эти хранимки sp_... это просто API сервера для работы с внешними запросами. Видимо были какие-то проблемы добавить методы аналогичные execute для параметризованных запросов, и они реализовали внешний интерфейс этой функциональности через хранимки, но какого-то недостатка я в этом не вижу..

Здравствуйте, pkarklin, Вы писали:

S>>- Вы говорите, что возможен только вариант с хранимкой
S>>- Merle говорит, что вариант без хранимки возможен, но менее эффективен.

S>>Собственно, меня удивляют оба варианта, но хотелось бы знать "как оно есть на самом деле".

P>Давайте опять разбираться с терминологией. Хранимки реализующие модель prepare\execute ODBC (sp_prepare, sp_execute, sp_uprepare) и хранимка sp_executesql — это системные хранимки. И они на писаны не на T-SQL, в отличаи

С этим не возникает вопросов. Скорее удивляет утверждение, что несистемные хранимки можно писать только на T-SQL (насколько я в курсе, MSSQL поддерживает UDF); что касается Oracle, хранимку можно писать практически на любом языке.

Но я не понимаю — для чего они, эти системные хранимки. Вернее, я могу понять их наличие для реализации, например, динамического SQL, но не очень понимаю, зачем вовлекать какие-то системные хранимки в процесс обработки "обычного SQL".

И все-таки хотелось бы знать: возможен ли вариант "без хранимок" или нет?

Здравствуйте, Merle, Вы писали:

S>>Имхо идеальный вариант — когда драйвер передает на сервер информацию типа
S>>

"select .... where a=? and b=?", 1 int,2 int

M>И чем это отличается от подстановки вызова хранимки перед запросом? Ничем, кроме синтаксиса.

Отличается отсутствием лишней сущности и свяанных с этим вопросов. Драйверу не нужно делать лишние странные действия, не возникает вопроса "что будет, если я определю собственную хранимку с именем sp_execute" и так далее. Система получается более простой, более замкнутой.

M>Вообщем, эти хранимки sp_... это просто API сервера для работы с внешними запросами. Видимо были какие-то проблемы добавить методы аналогичные execute для параметризованных запросов, и они реализовали внешний интерфейс этой функциональности через хранимки, но какого-то недостатка я в этом не вижу..

Это не то что недостаток, скорее странно. И наводит на мысль, что изначально такой возможности таки не было — в силу чего хранимки и были здорово быстрее — а потом ее добавили "сбоку", так чтобы минимально менять уже реализованное.

Здравствуйте, Softwarer, Вы писали:

S>Это растет из фразы Merle о том, что варианты с приходом "просто sql" и "sp_execute sql" различны по эффективности и сервер в общем случае не может преобразовать менее эффективный вариант в более эффективный.
Это была не совсем правильная фраза..
Там разный подход, немного в одном случа сначала готовится план, клиенту возвращается указатель на этот план, далее клиент вместе с указателем передает список значений и запрос выполняется.
Во втором случае запрос исполняется, параметризованный план остается в памяти, и используется при следующих вызовах.

Просто когда просматривал по диагонали sp_executesql наткнулся на фразу о преимуществах, но не прчитал в каких случаях и почему, ну и выводы сделал соответствующие. .

Здравствуйте, Softwarer, Вы писали:

S>С этим не возникает вопросов. Скорее удивляет утверждение, что несистемные хранимки можно писать только на T-SQL (насколько я в курсе, MSSQL поддерживает UDF); что касается Oracle, хранимку можно писать практически на любом языке.

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

S>Но я не понимаю — для чего они, эти системные хранимки. Вернее, я могу понять их наличие для реализации, например, динамического SQL, но не очень понимаю, зачем вовлекать какие-то системные хранимки в процесс обработки "обычного SQL".

Еще раз. Описанные здесь системные хранимки — единственно возможный вариант для сервера гарантированно повторно использовать план выполнения для ad hoc запросов.

S>И все-таки хотелось бы знать: возможен ли вариант "без хранимок" или нет?

НЕТ.