, когда вы объявляете permisson
в Manifest
, и это не означает, что вы выполняете Task в MarshMallow
, а для MarshMallow
вы установили Permisson в RunTime
.
, как этот путь
ActivityCompat.requestPermissions();
Запрос A совпадает с:
select 'true' where 3 = 1 or 3 = 2 or 3 = 3 or 3 = null
Так как 3 = 3
истинно, вы получаете результат.
Запрос B такой же, как:
select 'true' where 3 <> 1 and 3 <> 2 and 3 <> null
Когда ansi_nulls
включен, 3 <> null
НЕИЗВЕСТНО, поэтому предикат оценивает UNKNOWN, и вы не получите никаких строк.
Когда ansi_nulls
выключен, 3 <> null
истинно, поэтому предикат оценивает значение true, и вы получаете строку.
это для Мальчика:
select party_code
from abc as a
where party_code not in (select party_code
from xyz
where party_code = a.party_code);
работает независимо от настроек ansi
Null означает и отсутствие данных, то есть неизвестно, а не значение данных ничего. Это очень легко для людей из программирования, чтобы смутить это, потому что в языках типов C при использовании указателей null действительно ничего.
Следовательно, в первом случае 3 действительно находится в наборе (1,2,3, null), так что true возвращается
Во втором, однако, вы можете уменьшить его до
select 'true', где 3 не в (null)
Таким образом, ничего не возвращается, потому что анализатор ничего не знает о наборе, с которым вы его сравниваете, - это а не пустой набор, но неизвестный набор. Использование (1, 2, null) не помогает, потому что набор (1,2), очевидно, является ложным, но тогда вы и против этого неизвестны, что неизвестно.
В A, 3 проверяется на равенство по отношению к каждому члену набора, что дает (FALSE, FALSE, TRUE, UNKNOWN). Поскольку один из элементов TRUE, условие TRUE. (Также возможно, что здесь происходит короткое замыкание, поэтому он фактически останавливается, как только он достигает первого ИСТИНА и никогда не оценивает 3 = NULL.)
В B, я думаю, он оценивает условие как NOT (3 в (1,2, null)). Тестирование 3 для равенства по отношению к установленным доходностям (FALSE, FALSE, UNKNOWN), которое агрегируется в UNKNOWN. NOT (UNKNOWN) дает UNKNOWN. Таким образом, общая истина условия неизвестна, которая в конце по существу трактуется как ЛОЖЬ.
NOT IN
возвращает 0 записей при сравнении с неизвестным значением Поскольку NULL
является неизвестным, запрос NOT IN
, содержащий NULL
или NULL
s в списке возможных значения всегда будут возвращать записи 0
, так как нет способа убедиться, что значение NULL
не является тестируемым значением.
Всякий раз, когда вы используете NULL, вы действительно имеете дело с трехзначной логикой.
Ваш первый запрос возвращает результаты, поскольку предложение WHERE оценивается как:
3 = 1 or 3 = 2 or 3 = 3 or 3 = null
which is:
FALSE or FALSE or TRUE or UNKNOWN
which evaluates to
TRUE
Второй :
3 <> 1 and 3 <> 2 and 3 <> null
which evaluates to:
TRUE and TRUE and UNKNOWN
which evaluates to:
UNKNOWN
UNKNOWN не совпадает с FALSE, вы можете легко проверить его, вызвав:
select 'true' where 3 <> null
select 'true' where not (3 <> null)
Оба запроса не дадут вам результатов
Если UNKNOWN был таким же, как FALSE, то, предполагая, что первый запрос даст вам FALSE, второй должен был бы оценивать значение TRUE, поскольку он был бы таким же, как NOT (FALSE). Это не так.
В SqlServerCentral есть очень хорошая статья .
Вся проблема NULL и трехзначной логики может сначала немного сбив с толку, но для того, чтобы писать правильные запросы в TSQL
, необходимо понимать другую статью, которую я бы рекомендовал: SQL Aggregate Functions и NULL .
ЕСЛИ вы хотите фильтровать с помощью NOT IN для подзапроса, содержащего NULL, просто проверьте не null
SELECT blah FROM t WHERE blah NOT IN
(SELECT someotherBlah FROM t2 WHERE someotherBlah IS NOT NULL )
также может быть полезно знать логическую разницу между соединением, существует и в http://weblogs.sqlteam.com/mladenp/archive/2007/05/18/60210.aspx
Из ответов здесь можно сделать вывод, что NOT IN (subquery)
неправильно обрабатывает нули и его следует избегать в пользу NOT EXISTS
. Однако такой вывод может быть преждевременным. В следующем сценарии, зачисленном в Chris Date (Database Programming and Design, Vol 2 No 9, September 1989), NOT IN
обрабатывает нули правильно и возвращает правильный результат, а не NOT EXISTS
.
Рассмотрим таблицу sp
для представления поставщиков (sno
), которые, как известно, поставляют детали (pno
) в количестве (qty
). В таблице в настоящее время хранятся следующие значения:
VALUES ('S1', 'P1', NULL),
('S2', 'P1', 200),
('S3', 'P1', 1000)
Обратите внимание, что количество является нулевым, т. Е. Для записи факта, что поставщик, как известно, предоставляет детали, даже если в каком количестве неизвестно.
Задача состоит в том, чтобы найти поставщиков, которые известны номером запасной части «P1», но не в количествах 1000.
Следующие правила используют NOT IN
для правильной идентификации поставщика S2, only:
WITH sp AS
( SELECT *
FROM ( VALUES ( 'S1', 'P1', NULL ),
( 'S2', 'P1', 200 ),
( 'S3', 'P1', 1000 ) )
AS T ( sno, pno, qty )
)
SELECT DISTINCT spx.sno
FROM sp spx
WHERE spx.pno = 'P1'
AND 1000 NOT IN (
SELECT spy.qty
FROM sp spy
WHERE spy.sno = spx.sno
AND spy.pno = 'P1'
);
Однако в нижеприведенном запросе используется одна и та же общая структура, но с NOT EXISTS
, но неверно включает в себя поставщик S1 в результате (т.е. для которого значение равно null):
WITH sp AS
( SELECT *
FROM ( VALUES ( 'S1', 'P1', NULL ),
( 'S2', 'P1', 200 ),
( 'S3', 'P1', 1000 ) )
AS T ( sno, pno, qty )
)
SELECT DISTINCT spx.sno
FROM sp spx
WHERE spx.pno = 'P1'
AND NOT EXISTS (
SELECT *
FROM sp spy
WHERE spy.sno = spx.sno
AND spy.pno = 'P1'
AND spy.qty = 1000
);
Таким образом, NOT EXISTS
не является серебряной пулей, она, возможно, появилась!
Конечно, источником проблемы является наличие нулей, поэтому «реальным» решением является устранение эти нули.
Это может быть достигнуто (среди других возможных конструкций) с использованием двух таблиц:
sp
поставщиков, которые, как известно, поставляют детали spq
поставщиков, которые, как известно, поставляют детали в известных количествах , отметив, что, вероятно, должно быть ограничение внешнего ключа, где spq
ссылается sp
.
Результат может тогда быть получена с использованием реляционного оператора «минус» (являющегося ключевым словом EXCEPT
в стандартном SQL), например
WITH sp AS
( SELECT *
FROM ( VALUES ( 'S1', 'P1' ),
( 'S2', 'P1' ),
( 'S3', 'P1' ) )
AS T ( sno, pno )
),
spq AS
( SELECT *
FROM ( VALUES ( 'S2', 'P1', 200 ),
( 'S3', 'P1', 1000 ) )
AS T ( sno, pno, qty )
)
SELECT sno
FROM spq
WHERE pno = 'P1'
EXCEPT
SELECT sno
FROM spq
WHERE pno = 'P1'
AND qty = 1000;
Сравнение с null не определено, если вы не используете IS NULL.
Итак, при сравнении 3 с NULL (запрос A) он возвращает undefined.
I.e. SELECT 'true', где 3 in (1,2, null) и SELECT 'true', где 3 не в (1,2, null)
, выдаст тот же результат, что и NOT (UNDEFINED) undefined, но не TRUE