SQL Server с помощью подстановочного знака в В
Так как техническая часть получила довольно много ответов, мой комментарий как раз связан с путаницей , которая приводит к этому переработанному ключевому слову .
Будучи Python очень красноречивым языком программирования, злоупотребление ключевым словом более печально известно. Ключевое слово else прекрасно описывает часть потока дерева решений: «если вы не можете этого сделать, (иначе) сделайте это». Это подразумевается на нашем родном языке.
Вместо этого использование этого ключевого слова с утверждениями while и for создает путаницу. Причина, по которой наша карьера программиста научила нас тому, что утверждение else находится в дереве решений; его логическая область , обертка, которая условно возвращает путь, по которому нужно следовать. Между тем, циклические операторы имеют явно выраженную цель достичь чего-то. Цель достигается после непрерывных итераций процесса.
if / else указывают путь для следования . Петли следуют по пути, пока «цель» не будет достигнута .
Проблема в том, что else - это слово, которое четко определяет последний вариант в условии. Семантика слова этого слова совместно используется Python и Human Language. Но другое слово в человеческом языке никогда не используется для обозначения действий, которые кто-то или что-либо предпримет после того, как что-то будет выполнено. Он будет использоваться, если в процессе его завершения возникнет проблема (более похожая на инструкцию break ).
В конце ключевое слово останется в Python. Понятно, что это была ошибка, понятнее, когда каждый программист пытается придумать историю, чтобы понять ее использование как какое-то мнемоническое устройство. Я бы с удовольствием, если бы они выбрали вместо ключевого слова then. Я считаю, что это ключевое слово идеально вписывается в этот итеративный поток, выплату после цикла.
Это напоминает ту ситуацию, которая возникает у какого-то ребенка после выполнения каждого шага сборки игрушки: И ТО какой папа?
8 ответов
Как насчет:
WHERE LEFT(job_no, 4) IN ('0711', '0712', ...)
У вас есть ответ прямо в вашем вопросе. Вы не можете напрямую передать подстановочный знак при использовании IN. Однако вы можете использовать подзапрос.
Попробуйте следующее:
select *
from jobdetails
where job_no in (
select job_no
from jobdetails
where job_no like '0711%' or job_no like '0712%')
)
Я знаю, что это выглядит безумно, поскольку вы можете просто использовать OR в предложении WHERE. почему подзапрос? Однако подход с подзапросом будет полезен, когда вам нужно сопоставить детали из другого источника.
Raj
В Access SQL я бы использовал это. Я полагаю, что у SQLserver такой же синтаксис.
select * из подробностей работы где job_no как «0711 *» или job_no как «0712 *»
Оператор IN - не что иное, как причудливое ИЛИ сравнений "=". На самом деле это настолько «ничто иное, как», что в SQL 2000 была ошибка переполнения стека из-за расширения IN на OR s, когда список содержал около 10 тыс. Записей (да, есть люди, которые пишут 10к IN записей ...). Поэтому в нем нельзя использовать какие-либо подстановочные знаки.
SELECT c.* FROM(
SELECT '071235' AS token UNION ALL SELECT '07113'
UNION ALL SELECT '071343'
UNION ALL SELECT '0713SA'
UNION ALL SELECT '071443') AS c
JOIN (
SELECT '0712%' AS pattern UNION ALL SELECT '0711%'
UNION ALL SELECT '071343') AS d
ON c.token LIKE d.pattern
071235
07113
071343
Вы можете попробовать что-то вроде этого:
select *
from jobdetails
where job_no like '071[12]%'
Не совсем то, о чем вы спрашиваете, но имеет тот же эффект, а также гибкий в других отношениях:)
How about something like this?
declare @search table
(
searchString varchar(10)
)
-- add whatever criteria you want...
insert into @search select '0711%' union select '0712%'
select j.*
from jobdetails j
join @search s on j.job_no like s.searchString
Попробуйте это
select *
from jobdetails
where job_no between '0711' and '0713'
единственная проблема в том, что задание '0713' тоже будет возвращено.
так что можете использовать '07299999999999' или просто добавить и job_no <> '0713'
Dan zamir
.