Почему действительно АННУЛИРУЕТ =, ПУСТОЙ УКАЗАТЕЛЬ оценивает ко лжи в SQL-сервере
Во-первых, проанализируйте строку в наивный объект даты и времени. Это - экземпляр datetime.datetime без приложенной информации о часовом поясе. См. документацию для datetime.strptime для получения информации о парсинге строки даты.
Использование pytz модуль, который идет с полным списком часовых поясов + UTC. Фигура, каков локальный часовой пояс, создает объект часового пояса из него, и управляет и присоединяет его к наивной дате и времени.
Наконец, используйте datetime.astimezone() метод для преобразования даты и времени в UTC.
Исходный код, с помощью локального часового пояса "America/Los_Angeles", для строки "03.02.2001 10:11:12":
import pytz, datetime
local = pytz.timezone ("America/Los_Angeles")
naive = datetime.datetime.strptime ("2001-2-3 10:11:12", "%Y-%m-%d %H:%M:%S")
local_dt = local.localize(naive, is_dst=None)
utc_dt = local_dt.astimezone(pytz.utc)
Оттуда, можно использовать strftime() метод для форматирования даты и времени UTC по мере необходимости:
utc_dt.strftime ("%Y-%m-%d %H:%M:%S")
8 ответов
Думайте о нуле как о «неизвестном» в этом случае (или «не существует»). В любом из этих случаев вы не можете сказать, что они равны, потому что не знаете ценности ни одного из них. Итак, null = null оценивается как неверное (false или null, в зависимости от вашей системы), потому что вы не знаете значений, чтобы сказать, что они равны. Такое поведение определено в стандарте ANSI SQL-92.
РЕДАКТИРОВАТЬ: Это зависит от вашей настройки ansi_nulls . если у вас отключен ANSI_NULLS, это будет оцениваться как истина. Выполните следующий код для примера ...
set ansi_nulls off
if null = null
print 'true'
else
print 'false'
set ansi_nulls ON
if null = null
print 'true'
else
print 'false'
null неизвестен в sql, поэтому мы не можем ожидать, что два неизвестных будут одинаковыми.
Однако вы можете получить такое поведение, установив для ANSI_NULLS значение Off (по умолчанию включено) Вы сможете использовать оператор = для значений NULL
SET ANSI_NULLS off
if null=null
print 1
else
print 2
set ansi_nulls on
if null=null
print 1
else
print 2
NULL не равен чему-либо, даже самому себе. Мое личное решение для понимания поведения NULL состоит в том, чтобы по возможности избегать его использования :).
The question:
Does one unknown equal another unknown?
(NULL = NULL)
That question is something no one can answer so it defaults to true or false depending on your ansi_nulls setting.
However the question:
Is this unknown variable unknown?
Это совершенно другой вопрос, и на него можно ответить «истина».
nullVariable = null сравнивает значения
nullVariable is null сравнивает состояние переменной
Может быть, это зависит, но я думал, что NULL = NULL оценивается как NULL , как и большинство операции с NULL в качестве операнда.
В MSDN есть хорошая описательная статья о значениях NULL и трех логических состояниях, которые они порождают.
Короче говоря. , спецификация SQL92 определяет NULL как неизвестное, а NUL, используемый в следующих операторах, вызывает неожиданные результаты для непосвященных:
= operator NULL true false
NULL NULL NULL NULL
true NULL true false
false NULL false true
and op NULL true false
NULL NULL NULL false
true NULL true false
false false false false
or op NULL true false
NULL NULL true NULL
true true true true
false NULL true false
Здесь я, надеюсь, проясню свою позицию.
То, что NULL = NULL оценивается как FALSE , неверно. Хакер и Мистер правильно ответили NULL .
Вот почему. Дэуэйн Кристенсен написал мне в комментарии к Скотту Айви :
Поскольку сейчас декабрь, давайте использовать сезонный пример. У меня есть два подарка под деревом. Теперь скажи мне, если я есть два одинаковых предмета или нет.
Они могут быть разными или равными, вы не знаете , пока один из них не откроет оба подарка. Кто знает? Вы пригласили двух человек, которые не знают друг друга, и оба сделали вам один и тот же подарок - редкий, но не невозможный § .
Итак, вопрос: эти два НЕИЗВЕСТНЫХ представляют одно и то же (равно знак равно Правильный ответ: НЕИЗВЕСТНО (т.е. NULL ).
Этот пример был предназначен для демонстрации того, что «.. ( false или null , в зависимости от вашей системы) .. "правильный ответ - это не так, только NULL верен в 3VL (или вы можете принять систему, которая дает неправильные ответы?)
Правильный ответ на этот вопрос должен подчеркнуть следующие два момента:
- трехзначная логика (3VL) противоречит здравому смыслу (см. Бесчисленное множество других вопросов по этой теме в Stackoverflow и на других форумах, чтобы убедиться);
- СУБД на основе SQL часто не уважают даже 3VL, иногда они дают неправильные ответы (как и утверждается в оригинальном плакате, SQL Server в данном случае делает).
Итак, я повторяю: SQL не дает ничего хорошего, заставляя интерпретировать рефлексивное свойство равенства, которое гласит, что:
для любых x, x = x§§ (на простом английском языке: независимо от вселенной дискурса «вещь» всегда равна самой себе ).
.. в 3VL ( TRUE , FALSE , NULL ). Ожидания людей будут соответствовать 2VL ( ИСТИНА , ЛОЖЬ , что даже в SQL верно для всех других значений), т.е. x = x всегда оценивается как TRUE , для любого возможного значения x - без исключений.
Также обратите внимание, что NULL являются допустимыми « не значениями » (как их апологеты притворяются), которые можно присвоить как значения атрибутов (??) как часть переменных отношения. Таким образом, они являются приемлемыми значениями любого типа (домена), а не только типа логических выражений.
И это была моя точка : NULL , как значение, является " странный зверь ». Без эвфемизма я предпочитаю сказать: ерунда .
Я думаю, что эта формулировка гораздо более ясна и менее спорна - извините за мое плохое знание английского языка.
Это только один проблем NULL. По возможности лучше их полностью избегать.
§ нас беспокоят значений , поэтому тот факт, что два присутствующих являются всегда двумя разными физическими объектами, не является обоснованным возражением; Если вы не уверены, извините, здесь не место для объяснения разницы между семантикой значения и "объектной" (реляционная алгебра изначально имеет семантику значений - см. принцип информации Кодда; я думаю, что некоторые разработчики СУБД SQL не даже не заботится об общей семантике.)
§§ насколько мне известно, это аксиома, принятая (в той или иной форме, но всегда интерпретируемая в 2VL) с древних времен, и это точно потому что это настолько интуитивно понятно. 3VL (на самом деле это семейство логик) - это гораздо более поздняя разработка (но я не уверен, когда была впервые разработана).
Примечание: , если кто-то представит типы Нижний , Блок и Вариант ] как попытки оправдать значения SQL NULL, я буду уверен только после достаточно подробного изучения, показывает, как реализации SQL с NULL имеют систему звуковых типов, и проясняет, наконец, что такое NULL (эти «значения-не-совсем-значения») на самом деле.
Далее я процитирую некоторых авторов. Любая ошибка или упущение
Далее я процитирую некоторых авторов. Любая ошибка или упущение
Далее я процитирую некоторых авторов. Любая ошибка или упущение вероятно, мой, а не первоначальных авторов.
Джо Селко о SQL NULL
Я вижу, что Джо Селко часто цитируется на этом форуме. Судя по всему, он здесь очень уважаемый автор. Итак, я сказал себе: «Что он написал о SQL NULL? Как он объясняет многочисленные проблемы с NULL?». У одного из моих друзей есть электронная версия SQL для умников Джо Селко: расширенное программирование SQL, 3-е издание . Посмотрим.
Во-первых, оглавление. Больше всего меня поражает количество упоминаний NULL в самых разных контекстах:
3.4 Арифметика и NULL 109
3.5 Преобразование значений в NULL и обратно 110
3.5.1 Функция NULLIF () 110
6 NULL: отсутствующие данные в SQL 185
6.4 Сравнение NULL 190
6.5 NULL и логика 190
6.5.1 NULL в предикатах подзапроса 191
6.5.2 Стандартные решения SQL 193
6.6 Математика и NULL 193
6.7 Функции и значения NULL 193
6.8 NULL и языки хоста 194
6.9 Рекомендации по проектированию для NULL 195
6.9.1 Как избежать значений NULL в хост-программах 197
6.10 Примечание о множественных значениях NULL 198
10.1 IS NULL Предикат 241
10.1.1 Источники NULL 242
...
и так далее. Для меня это звучит как «неприятный особый случай».
Я буду разбирать некоторые из этих случаев с выдержками из этой книги, пытаясь ограничиться основным из соображений авторского права. Я думаю, что эти цитаты подпадают под доктрину «добросовестного использования», и они могут даже стимулировать покупку книги - так что я надеюсь, что никто не будет жаловаться (иначе мне придется удалить большую часть, если не все). Кроме того, я воздержусь от сообщения фрагментов кода по той же причине. Прости за это. Купите книгу, чтобы прочитать о рассуждениях на основе данных.
Номера страниц в скобках в нижеследующем.
Ограничение NOT NULL (11)
Наиболее важным ограничением столбца является NOT NULL, которое запрещает использование NULL в столбце. Регулярно используйте это ограничение и удалите это только тогда, когда у вас есть веская причина. Это поможет вам избежать осложнения значений NULL при выполнении запросов к данным.
Это не значение ; это маркер, который удерживает место, куда может идти значение.
Опять же, чепуха о «значении, но не совсем о значении». Остальное мне кажется вполне разумным.
(12)
Короче говоря, значения NULL вызывают в SQL множество необычных функций, которые мы обсудим позже. Лучше всего просто запомнить ситуации и правила для NULL. когда вы не можете их избежать.
По поводу SQL, NULL и бесконечности:
(104) ГЛАВА 3: ЧИСЛОВЫЕ ДАННЫЕ В SQL
SQL не принял модель IEEE для математики по нескольким причинам.
. ..
Если бы математические правила IEEE были разрешены в SQL, тогда нам понадобятся правила преобразования типов для бесконечности и способ представляют собой бесконечное точное числовое значение после преобразования. люди у меня достаточно проблем с NULL, поэтому давайте не будем туда идти.
Реализации SQL не определились с тем, что на самом деле означает NULL в определенных контекстах:
3.6.2 Экспоненциальные функции (116)
Проблема в том, что логарифмы не определены, когда ( х <= 0). Некоторый SQL реализации возвращают сообщение об ошибке, некоторые возвращают NULL и DB2 / 400; версия 3, выпуск 1 вернула * НЕГИНФ (сокращение от «отрицательная бесконечность») как результат.
Джо Селко цитирует Дэвида МакГоверана и CJ Date:
6 NULL: Отсутствующие данные в SQL (185)
В своей книге A Guide to Sybase and SQL Server Дэвид МакГоверан и CJ Date сказал: «Это мнение автора, а не NULL, по крайней мере, как в настоящее время определены и реализованы в SQL, гораздо больше проблем, чем они стоят того, и их следует избегать; они выглядят очень странно и непоследовательное поведение и может стать источником ошибок и путаницы. (Обратите внимание, что эти комментарии и критика относятся к любой системе который поддерживает NULL в стиле SQL, а не только для SQL Server.) »
NULL как наркомания :
(186/187)
В остальной части этой книги Я буду убеждать вас не использовать их , что может показаться противоречивым, но это не так. Подумайте о NULL как наркотик; используйте его правильно, и он работает на вас, но злоупотребляйте им, и он может испортить все. Лучше всего избегать значений NULL, когда это возможно, и использовать их должным образом, когда это необходимо.
Мое единственное возражение здесь состоит в том, чтобы «использовать их должным образом», что плохо взаимодействует с специфическое поведение реализации.
6.5.1 NULL в предикатах подзапроса (191/192)
Люди забывают, что подзапрос часто скрывает сравнение с NULL. Рассмотрим эти две таблицы:
...
Результат будет пустым. Это нелогично , но верно.
(разделитель)
6.5.2 Стандартные решения SQL (193)
SQL-92 решил некоторые из задач 3VL (трехзначной логики) путем добавление новый предикат формы:
<условие поиска> ЕСТЬ [НЕ] ИСТИНА | ЛОЖЬ | НЕИЗВЕСТНЫЙ
Но НЕИЗВЕСТНЫЙ сам по себе является источником проблем, поэтому CJ Date, в его книге, цитируемой ниже, рекомендуется в главе 4.5. Предотвращение пустых значений в SQL :
- Не используйте ключевое слово UNKNOWN ни в каком контексте.
Прочтите «ASIDE» в UNKNOWN, также ссылка на которую приведена ниже.
6.8 NULL и Host Языки (194)
Однако вы должны знать, как обрабатываются NULL, если они для передачи в хост-программу. Нет стандартного языка хоста для которое определено встраиванием, поддерживает NULL, что является еще одним хорошая причина избегать их использования в схеме базы данных.
(разделитель)
6.9 Рекомендации по проектированию для значений NULL (195)
Рекомендуется объявить все базовые таблицы с NOT NULL ограничения на все столбцы, когда это возможно. NULL сбивают людей с толку кто не знает SQL, а NULL обходятся дорого.
Возражение: NULL сбивает с толку даже людей, которые хорошо знают SQL, см. ниже.
(195)
В FOREIGN KEY следует избегать использования NULL. SQL позволяет это «преимущество сомнения », но это может привести к потере информации в запросы, включающие соединения. Например, учитывая код номера детали в Инвентарь, который указан как ИНОСТРАННЫЙ КЛЮЧ в таблице заказов, вы будут проблемы с получением списка частей, которые имеют NULL. Это обязательные отношения; вы не можете заказать часть, которая не существует.
(разделитель)
6.9.1 Избегание NULL из хост-программ (197)
Вы можете избежать помещения NULL в базу данных из хост-программ с некоторой дисциплиной программирования.
...
- Определите влияние отсутствующих данных на программирование и отчетность: Числовые столбцы с NULL представляют собой проблему, поскольку запросы использование агрегатных функций может привести к ошибочным результатам.
(разделитель)
(227)
SUM () пустого набора всегда имеет значение NULL. Один из самых распространенных ошибки программирования, допущенные при использовании этого трюка, заключаются в написании запроса, который может возвращать более одной строки. Если бы вы не думали об этом, вы могли бы записали последний пример как: ...
(разделитель)
10.1.1 Источники NULL (242)
Важно помнить, где могут встречаться NULL. Их больше, чем только возможное значение в столбце . Агрегатные функции на пустых наборах, OUTER JOINs, арифметические выражения с NULL и операторы OLAP все возвращают NULL. Эти конструкции часто отображаются в виде столбцов в ПРОСМОТРЫ.
(разделитель)
(301)
Другая проблема с NULL обнаруживается при попытке преобразовать Предикаты IN для предикатов EXISTS.
(разделитель)
16.3 ВСЕ функции предикатов и экстремумов (313)
Поначалу кажется парадоксальным, что эти два предиката не совпадают в SQL:
...
Но вы должны помнить правила для экстремальных функций - они удалите все значения NULL перед возвратом большего или меньшего значения. В Предикат ALL не отбрасывает значения NULL, поэтому вы можете получить их в результатах.
(разделитель)
(315)
Однако определение в стандарте сформулировано в отрицательный, так что NULL получают преимущество при сомнении. ...
Как видите, рекомендуется избегать NULL в UNIQUE ограничения.
Обсуждение GROUP BY:
NULL обрабатываются так, как если бы все они были равны друг другу , и образуют собственную группу. Каждая группа затем сокращается до одного строка в новой таблице результатов, которая заменяет старую.
Это означает, что для предложения GROUP BY NULL = NULL не оценивается как NULL, как в 3VL, но оценивается как TRUE.
Стандарт SQL сбивает с толку:
ORDER BY и NULL (329)
Считается ли значение ключа сортировки, равное NULL, большим или меньшим, чем а значение, отличное от NULL, определяется реализацией, но ...
... Есть продукты SQL, которые делают это в любом случае.
В марте 1999 года Крис Фаррар поднял вопрос от одного из своих разработчиков, которые заставили его изучить часть стандарта SQL, Я думал, что понял . Крис обнаружил некоторые различия между общее понимание и актуальная формулировка спецификации .
И так далее. Я думаю, что Celko достаточно.
CJ Date в SQL NULL
CJ Date более радикален в отношении NULL: избегайте NULL в SQL, точка. Фактически, глава 4 его SQL и Relational Theory: Как писать точно Код SQL озаглавлен «NO DUPLICATES, NO NULLS», с подразделами «4.4 Что не так с пустыми значениями?» и «4.5 Как избежать пустых значений в SQL» (перейдите по ссылке: благодаря Google Книгам вы можете читать некоторые страницы в режиме онлайн).
Фабиан Паскаль о значениях SQL NULL
Из его Практические вопросы управления базами данных - Справочник для практикующего мышления (в Интернете нет выдержек, извините):
10.3 Практические последствия
10.3.1 SQL NULL
... SQL страдает от проблем, присущих как 3VL, так и многим другим причуды, сложности, нелогичность и явные ошибки [10, 11]; среди них следующие:
- Агрегатные функции (например, SUM (), AVG ()) игнорируют значения NULL (кроме COUNT ()).
- Скалярное выражение в таблице без строк неправильно оценивается как NULL, а не 0.
- Выражение «NULL = NULL» оценивается как NULL, но фактически недопустимо в SQL; тем не менее, ORDER BY рассматривает NULL как равные (независимо от того, что они предшествуют или следуют за "обычными" значениями, остается за поставщиком СУБД).
- Выражение "x IS NOT NULL" не равно "NOT (x IS NULL)", как и случай в 2VL.
...
Все коммерчески реализуемые диалекты SQL следуют этому подходу 3VL и, таким образом, они не только решают эти проблемы, но также имеют конкретную реализацию проблемы, которые различаются в зависимости от продукта .
Just because you don't know what two things are, does not mean they're equal. If when you think of NULL you think of “NULL” (string) then you probably want a different test of equality like Postgresql's IS DISTINCT FROM AND IS NOT DISTINCT FROM
From the PostgreSQL docs on "Comparison Functions and Operators"
expression
IS DISTINCT FROMexpressionexpression
IS NOT DISTINCT FROMexpressionFor non-null inputs,
IS DISTINCT FROMis the same as the<>operator. However, if both inputs are null it returns false, and if only one input is null it returns true. Similarly,IS NOT DISTINCT FROMis identical to=for non-null inputs, but it returns true when both inputs are null, and false when only one input is null. Thus, these constructs effectively act as though null were a normal data value, rather than "unknown".