- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
SELECT *
FROM Elements e
WHERE NULL NOT IN (NULL);
-- пусто
SELECT *
FROM Elements e
WHERE NULL IN (NULL);
-- пусто-
SQL / Говнокод #16488
−79
Вот такой вот парадокс. Подробнее
http://sqlfiddle.com/#!2/00c3a7/5
http://sqlfiddle.com/#%212/00c3a7/4
Ключ к разгадке тут:
http://docs.oracle.com/cd/B19306_01/server.102/b14200/sql_elements005.htmЗапостил:
Elvenfighter,
06 Августа 2014
Follow us!
http://en.wikipedia.org/wiki/Ternary_logic
BREAKING NEWS
Но это же не правда! Как, впрочем, и не ложь.
Вот-вот :)
Если с этой точки зрения смотреть, то:
NULL IN (NULL) -- это FALSE
но
NULL NOT IN (NULL) -- должно быть TRUE
Не должно. Любые сравнения с аргументом NULL (кроме IS NULL) возвращают false. В частности NULL = NULL -> false, NULL != NULL -> false. Операции над NULL возвращают NULL.
Аналогично ведёт себя NaN.
Да нет же, не false они возвращают! Не путай людей ;)
Все сравнения с NULL'ом возвращают третье состояние була (в разных СУБД обозначают по-разному, пусть будет просто NULL). И именно поэтому вся дальнейшая логика с этим результатом тоже возвращает это третье состояние.
А вот условные операторы трактуют это значение как false, у них выбора особо и нет.
И именно поэтому where a = null or a <> null or (not (a = null)) or (not (a <> null) ничего не выберет.
Вот тут я гоню - не вся логика. unknown or true и false and unknown вернут не unknown, а нормальное значение.
Да, я сегодня что-то слишком волен в выражениях.
>> A condition that evaluates to UNKNOWN acts almost like FALSE
Любые сравнения с аргументом NULL (кроме IS NULL) возвращают почти false.
where null in (null) is null;
mysql такой mysql
default '' primary key это вообще за гранью блеать!
эта какашка вылезла после нескольких редактирований и перезаливов. Изначально задание было другое (и условия тоже). Рефакторинг, такой рефакторинг O:-)
учиться на нем sql нельзя
> MySql
No way!
Да ну. Графический конструктор запросов можно много куда привернуть.
SQL быстро забывается, а тут хоть польза будет. Я его два раза забывал, так до конца и не вспомнил.
Очень зависит от проекта.
на брейнбенче есть ansi sql тест
скучный, правда
Каждая СУБД позволит тебе погрузиться в неповторимый мир отклонений от стандарта, уникальных расширений, приёмов и костылей которые есть только в ней и нигде больше...
И если твой проект представляет собой что-то посложнее тупенького CRUD'а, то готовься к анальному рабству - ты никогда не перенесешь проект на другую СУБД, особенно если юзал хранимки.
Скажем так - если проект пилили больше года, то это вообще нереально.
http://govnokod.ru/13032
А если речь идёт о работе с базой, её настройках, хранимых процедурах, индексах и пользователях, то надо подумать и, может быть, не вспоминать вовсе.
SQL быстро заёбывает
fxd
А в Asp.Net юзается linq
В одной конторе, вообще база только через ADO.NET используется. Т.к. меедленно.
В другой, (благо одумались в последнее время...) вообще свой провайдер на крестах для .NET'а написали.
У нас тоже ходили слухи о написании своего провайдера, благо за пару недель отговорить получилось...
Просто про основы, мало кому интересно слушать, вот и пишут на публику про всякие ORM'ы.
Даже оф. документация по ASP.NET WebForms 2.0 содержала в себе не использование ADO.NET, а SqlDataSource.
Дабы dev не написал такой "годный" код:
А мне, WebForms даже ближе чем MVC, т.к. не фанат рантайм компиляций.
Ещё во времена "ASP.NET Web Site"'ов накушался...
Хотя, по существу, поведение контроллера ASP.NET MVC, отдалённо напоминает работу ISAPI модулей.
Честно с вебом работал немного, прочитал пару книжек, попробовал на пальцах
Соответственно, DAL в своих решениях, BLL всё это объеденяет в следующем решении, подцепляет сервисы и работает с распределённым кешем, а морды уже используют как хотят. И всё это горизонтально масштабируется на фермах с использованием DFS и NLB.
Ну и всё это под надзором TFS'а.
подходит только для безрукого мудака, который хочет делать сайт мышкой, и которому насрать на проблемы кастомизации и сопровождения
> MVC
именно
только тонкий сервер, только гетеросексуальность
так победим
Любой "безрукий", который учился по туториалам M$, в один прекрасный момент замечает, что у него "как-то сильно тормозит браузер" и после вьюстейта в Over 9000, бежит по умолчанию выключать ViewState в конфиге и забывает про дизайнер форм, как про страшный сон.
А нормальные разработчики, ещё со времён ASP.NET 3.5 (Или 2.0, не помню точно), вовсю использовали типизированные гриды и репитеры.
Пример:
http://www.codeproject.com/Articles/18049/A-Typed-Repeater-in-ASP-NET
данные и визуализация этих данных должны соединяться на клиенте, а не на сервере
причем поступать на клиент по желанию и мере надобности этого самого клиента
тогда котятки не будут умирать
Сказал - как отрезал :)
У нас - клиент в приоритете.
И клиент - никому ничего не должен, кроме как отдать нам часть своих денег.
Хоть ExtJS на титульной странице подгрузи в полном объёме.
Его скрипты и ресурсы - больше 3 метров весят.
> Его скрипты и ресурсы - больше 3 метров весят.
Опять же, смотря какой сайт. Если это визитка - то само-собой нахуй-нахуй. А если это сервис, в котором человек зависает каждый день по несколько часов - why not? Трафик и время отклика на чистом REST'е всяко будут лучше, чем при рендере на серваке => работать будет приятней. А загрузка сраного десятка метров после обновления скриптов никому не помешает.
Главное - чтобы автоматическая подгрузка работала, чтоб открытие сайта где-нибудь в е*енях не превращалось в увлекательную лотерею "угадай момент, когда все скрипты прогрузились сразу и до конца".
Только за сегодня, на главный фронт пришло 917 юников с MSIE6 (Благо, это меньше 1% от всех юников)...
И вот, блин, хоть и "message" на 30% экрана про обновление клиента, но всё равно продолжают пользоваться ослом...
Да и не всякие клиенты выдерживают тот мусор, который на них сайты сваливают.
Мой старый ноут, на WinXP и с последней авророй, на onLoad некоторых сайтов зависает секунд на 5-10.
Уголки скругить средствами jQuery? Пожалуйста.
Пробежаться 100500 раз по всем ul/li в DOM? Да как нефиг делать! Ведь всего одна строка в коде.
http://web.archive.org/web/20121031054037/www.radugainternet.ru/tarify/bezlimitnye/opera-mini.php
Придётся поддержать TauSigma.
Для сайта лучше рендер на серваке. Чтобы и отображался всяким дерьмом, не умеющим в скрипты, и индексировался нормально.
А вот для приложения лучше REST и рендер на клиенте - отклик быстрее, трафика меньше, в разработке проще. Да и с оперы мини один хуй нормально работать не получится, если ты не мазохист.
веб-сайт и должен быть веб-приложением SPA
если у тебя в браузере отключен js, значит тебе и в интернете делать нечего
выбери себе ОС, чтобы она не запускала исполняемые файлы, а только давала читать текстовые
выбери себе эвм, в которой не то, что нет видеоускорения, а которая умеет только в монохромный текстовый вывод
это ведь так современно
Поисковики же не одобрят...
Я вот в чем вижу разницу:
Сайт - ориентация на контент, хорошее индексирование поисковичками, по возможности человекопонятные ссылки на различные объекты сайта и чтобы побыстрее грузилось в первый раз (т.к. дофига мимопроходилов). Пример - википедия, говнокодик, всякие визитки да инет-магазины (со стороны клиента, не бекофис).
Приложение - ориентация на длительную работу, всем похуй, сколько оно грузится в первый раз, а вот отклик хотелось бы побыстрее, интерфейс без перезагрузок страницы. А ссылки на середину приложения и индексирование поисковиками нахер не нужны. Пример - email сервак типа mail.ru или gmail, бекофисы тех же инет-магазинов.
Ну это лично мое мнение, я могу ошибаться...
если твой поисковик настолько убог, что ты не можешь проиндексировать SPA с json данными, лежащими прямо перед тобой, то ты просто будешь терять долю рынка и терпеть прямой убыток
http://ng-learn.org/2014/05/SEO-Google-crawl-JavaScript/
пыховебформс, рендеринг на сервере, вендорлок - вчерашний день
/thread
Из непридуманой истории: в конторе, где я сейчас работаю, есть сервис, которые генерирует для пользователей видео и аплоадит его на Ютуб, так вот месяц назад случайно от этого видео отвалилась ссылка на наш сайт - казалось бы мелочь (экспорт в Ютуб - даже и не близко к основному продукту), но статистика гугла по поискам упала на 75% в Штатах (в общем примерно на 60%). Что как бы намекает на отсутствие значимой корреляции между контентом и обнаружением в поисковиках, и очень сильную корреляцию между появлением ссылки на посещаемом ресурсе и обнаружаемостью.
клиент (браузер, мобильный, толстый, etc) должны брать свой дизайн/статику отдельно, код отдельно, а данные с сервера отдельно и независимо от статики
сервер должен заниматься обслуживанием REST запросов, и только ими
он сервис данных, он даёт API, открытое или защищенное
никакой верстки он навязывать не должен
веб-клиент может брать свою статику с того же веб-сервера, но это развязанный от основной серверной задачи процесс, он кешируется на обеих сторонах, может обслуживаться nginx и чем угодно
технология веб-клиента никак не вендор-лочится на технологии сервера
таким образом ты можешь тасовать логику, дизайн, наконец, тип клиента, писать его не только для браузера на js, да хоть для дельфятного говна, возможно даже делать его не сам, предложить всем заинтересованным сделать 10 разных реализаций, пофиг
всё гибко и просто
а бекофис... сейчас у нас на руках есть чужая ынтерпрайзная система, в которой бекофис сделан на JSF (это собрат-дибил вебформ), неприятно, когда одна сраная страница с настройками одной сущности грузится по 30 секунд и более, нихуя не управляема, не расширяема и не сопровождаема
это ад, друзья
Может быть, в скором времени, когда такая схема будет использоваться везде, я перестану ненавидеть веб-технологии...
> Может быть, в скором времени, когда такая схема будет использоваться везде, я перестану ненавидеть веб-технологии...
Будет срач "Скачайте новый iБраузер: каждое веб-приложение - с яблочком!" / "Опять эти скучные обои в моём браузере? Качайте BolgeNet++" / "Вот скачал свободные гуи для гуглопочты, bash.im и лора, а они на C, python и ни черта не компилятся" / "Почему мой сервер в списке заблокированных? Я не виноват, что кулхацкеры написали скин с порнографией и самоубийствами!"
А поскольку в комментариях используется форматирование, что-то парсить всё равно придётся.
Фронтов-то на всех хватит?
Сейчас и так гуголь всех ES программеров скупает, скоро к нему ещё и M$ с WinRT присоединится...
Я могу заблуждаться, но кажется MS что то такое двигала в идеях WCF. Веб служба крутится, при связи с дотнетом выдает данные в своем формате, для всех остальных json - обрабатывай как хочешь и чем хочешь
Да эти идеи были задооолго до WCF.
Тому же SOAP'у уже черти сколько лет.
Соответственно - абстракция от транспорта.
А минусами - непредсказуемые исключения в процессе исполнения и адовы конфиги...
У меня много в чём отдают и принимают. REST и MQ - в том числе.
>таким образом ты можешь тасовать логику, дизайн, наконец, тип клиента, писать его не только для браузера на js, да хоть для дельфятного говна
Сервера BL ещё и платёжными транзакциями занимаются. Их наружу никто не пустит.
>веб-клиент может брать свою статику с того же веб-сервера
Мы - внешний CDN подключили, чтобы обеспечить быструю доступность вторичного траффика удалённому клиенту.
>технология веб-клиента никак не вендор-лочится на технологии сервера
Ну, с грамотными серверами BL и обёрткой, у меня получилось, что для WebApi - документации в 2 раза больше чем кода :)
>неприятно, когда одна сраная страница с настройками одной сущности грузится по 30 секунд и более
Титульная страница фронта на WebForms для авторизованного клиента грузится за 1.3-1.5 сек.
И весит 570Кб со всеми стилями, скриптами, формами, вьюстейтами, аяксами, картинками, баннерами, счётчиками и т.п.
Для гостя - чуть меньше, т.к. там аякса нет.
Warmup этого фронта на WebForms занимает - не более 5 секунд.
Вот BL сервера поднимаются тяжело, т.к. там уже вовсю кеши тягаться начинают...
Так, с йандексом у меня давнишние тёрки. И если у меня был бы выбор, пользоваться красивым шпионящим поисковиком с динамическим нахрен не нужным поиском, или пользоваться нерабочей его версией, я бы просто сменил поисковик.
Дык уже есть. Яндекс-метрика. Она не то что переходы сливает, но даже клики...
Бессмысленная паранойя, имхо. Они и без живого поиска знают что ты ищешь (т.к. они и так его видят) и результаты знают, и куда переходишь знают (т.к. вместо прямых ссылок дают редиректор).
Если они что-то новое скриптами и узнают - так это скорость твоего набора да частоту твоих опечаток.
Если уже пилят систему, которая узнает злоумышленника в их аккаунте, то значит много научились узнавать. Поднимет eth0 с земли чей-то смартфон в темноте, наберёт в поиске "узнать владельца смартфона для чайников", а поиск ему "Привет, eth0! У Вас три непрочитанных сообщения! Кликните тут, чтобы войти в аккаунт без пароля".
Да даже на тор перейти...
С тором, к стати, беда выходит. У него известен список адресов, которые могут выходить на определённый сайт. Мы, чтобы деанонимизировать клиента, просто блокируем доступ всему списку этих самых адресов...
Приходишь в магазин, а там тебя встречает неизвестная тётка "Здравствуйте, X Y, вам как и в прошлый раз три шуруповёрта и бутылку виски?" Кто это? Зачем она тут? Неловко и неприятно, когда кто-то рядом слишком много знает.
А у тётки просто память на лица хорошая...
А ты представь себе, сколько бизнес готов потратить на такое решение. ^_^
Да и с со стороны клиента, это лучше заученной фразы: "Здравствуйте, чем вам помочь?"
А смс с именами уже шлют. И, по-хорошему, надо спрашивать пользователя, готов ли он, чтобы этот конкретный магазин называл его по имени, или нет.
Пусть они знают, кто я, где живу и как часто пишу комментарии на ГК, пусть они ненавязчиво рекомендуют мне что-то новое на основе моих предыдущих покупок, но обращаются как с незнакомым человеком, который пришёл в первый-второй раз.
У нас - государство светское. С теократией - это к душманам и мусульманам. :)
>А тут внезапно в магазине бесцеремонно вторгаются в самый близкий слой.
Если я дал своё согласие, то пусть обращаются. Тем более, если мне в очередной раз не придётся объяснять зачем я к ним явился.
Ты-ж затеняешся от передачи своих предпочтений поисковику, а не от передачи своих персональных данных.
>А смс с именами уже шлют.
Нет согласия - дорога в ФАС.
Благо, с электронным праительством даже попу отрывать не надо.
Я пару раз уже пользовался этой фичей.
Да, я в курсе.
> и куда переходишь знают (т.к. вместо прямых ссылок дают редиректор)
Не знают.
У меня с дветыщщи-бородатого-года стоят скрипты разные, которые редиректы успешно вычищают.
А вот недавно у меня пригорало, когда я понял, что у этих блядей стоит глобальный ловец клика на странице и при включенном в NoScript йандексе постоянно лезут запросы на каждый клик. Соответственно, я перехожу по ссылкам с нажатия Ctrl+ссылка, что отправляется прямо в йандекс.
Пока прямого решения я не придумал, но если бы я был злым, я бы просто сделал таких запросов сто штук в секунду в цикле с рандомными координатами, а потом посмотрел, что они с этой "статистикой" стали бы делать.
@TauSigma
> Интернеты построены на принципе, что прятать нечего.
Дело не в инторнетах. Так мой провайдер вполне знает всю мою историю поиска вычурного прона и меня это не смущает. В конце концов, я же увлекаюсь не зоопедонекропроном.
Я именно негодую от того, что они хотят для каких-то своих ебучих целей выяснять не только то, что я ищу (это они знают), но и что нашёл. А вот это не должно их ебать вообще.
Задача поисковика не подсказать по первым буквам быстро-быстро "погода в мухосранске дождь +19", нет. Задачав - выдать мне сраную страницу со ссылками, а что я делать буду с ними дальше - их волновать не должно.
> Задачав - выдать мне сраную страницу со ссылками, а что я делать буду с ними дальше - их волновать не должно.
Но если у них получилось показать то, что я ищу, или вставить годные варианты запросов, то я только рад. Поисковик выполнил задачу: я искал, чему равно пи, мне сразу показали, не надо доставать калькулятор или нагружать сервера Википедии.
Смотрел презенташку йандекс-стрингов. Все поводы гордости были в "нескучных обоях", "показывает погоду", "теперь со вкусом апельсинов". А, ещё косноязычный дирехтор, который мнит себя жопсом.
P.S. Вот ты ищешь, скажем, что-нибудь очевидное. Например, дом четырнадцать дробь восемьдесят восемь. Но йандекс умный! Йандекс знает, что дробь - это деление! Так что получи в ответ 0,159(09).
И таких результатов поисков у меня были десятки, всё на уровне капитанской очевидности.
датабейс ундефаенд бихэвиорр!
WHERE Field_with_null_value NOT IN (Non_null_value_1, Non_null_value_2, Non_null_value_3 ... Non_null_value_N)
И плачут после этого - "пачиму строка не попала в выборку?"
Due to the vast experience, our team offers additional income from investments in the cryptocurrency exchange market.
<a href=https://wbtcstock.com/page/23/check-your-investment-status-on-all-hyip><img>http://wbtcstock.com/wbtcstock468.gif</img> </a>
Investment Plans:
S-Trader Duration deposit 39 days profit of 0.5% per day
M-Trader Duration deposit 69 days profit of 0.75% per day
B-Trader Duration deposit 120 days profit of 1% per day
Pro-Trader Duration deposit 150 days profit of 1.25% per day
We offer a flexible affiliate program to our customers with three levels designed to suit your needs.
Level 1: You will receive 10% for any person that registers a new account and places a deposit with our company.
Level 2: You will also receive an additional 5% of any deposit that is made by one of your sub referrals.
Level 3: We will add another 3% to any of your sub referral’s assignees that make a deposit.
<a href=https://wbtcstock.com/page/24/the-best-high-yield-investment-programs>Please follow this link for the Signup</a>
We have all the conditions for our clients to invest their funds without wasting too much time and to gain high profits.
Our company developed a unique trading method that guarantees 100% profit regardless of cryptocurrencies quotes volatility.
The company permanently looks for new and vacant cryptocurrencies for further investments.
It's not a secret that the main cryptocurrency cost $0.01 six-seven years ago that is 450 times less than today.
<a href=https://wbtcstock.com/page/9/investment-programs-non-hyip>online investment program
</a>
<a href=http://wbtcstock.com/reviews>Duration deposit 69 days profit of 0.75% per day
</a>