Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
 Re: Возможно ли вписать CASE в условие WHERE  [new]
~
Guest
Lily V.,
А почему бы тогда "between" не оставить, задав время для конца диапазона?
В частных случаях вам и к < (<= ) время подставлять придется
10 янв 14, 13:16    [15396223]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
Lily V.
Member

Откуда: Магнитогорск
Сообщений: 92
~
Lily V.,
А почему бы тогда "between" не оставить, задав время для конца диапазона?
В частных случаях вам и к < (<= ) время подставлять придется

Можно и так, не спорю. Вопрос же не в том, как лучше получать даные, а, в том, что если бы изначально было <, то, возможно, сейчас не нужно было бы заморачиваться со временем в принципе. Все это чисто гипотетически. все методы имеют право на существование, как говорится. и предлагаю уже эту тему - "за" и "против" использования BETWEEN.. - закрыть
10 янв 14, 13:30    [15396343]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
~
Guest
Lily V.,
А можно было и не избежать, если поменялся регламен например на: "данные нужны на 13 часов 47 минут 00 секунд".
Но, в общем, я с вами согласен.
10 янв 14, 13:36    [15396393]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Maxx
Но ,вы,совершенно не поняли о чем здесь шла речь в принцыпе.
OlM, так и не удосужился внятно объяснить в чём же был, так называемый "спор".
Lily V.
бо действительно проще было написать BETWEEN
Честно, не понимаю почему проще.
Ну, точнее я понимаю то субъективное ощущение которое возникает при этом. Но я понимаю что многие понимают эту субъективность восприятия и исправляя это когнитивное искажение понимают, что это проще сравнимо как:
пробежать километр или километр и один метр. Забудем про то,что пробежав на 0.1% меньше схлопочешь пулю в лоб с вероятностью 99.9% (переписывание кода). Дело в том что при этом на плечах будешь таскать рюкзак с пару лишних кило: два формата описания условий вместо одного и подсчёт конца периода, который надо делать при каждом шаге.

Lily V., прошу вас хоть как написать ваше восприятие почему BETWEEN проще.

Я конечно понимаю что логика вещей у гуманитариев не имеет никакого веса, они её не чувствуют, но это их проблема неадекватного восприятия.
И пытаться логически доказать своё неадекватное восприятие - это забавно.
Хотя я согласен, они пытаются доказать не логически, а доказать эмоционально. Что ещё более забавнее ставить два понятия как "доказать" и "ощущения".
А главное приходится. Аналогии делать, описывать через ощущения и восприятие.

Lily V.
Лично для себя я сразу же оценила предпочтение использования. у нас сейчас как раз подобная ситуация, о которой предупреждал Minor.
Не лично вам сказано, но это восприятие будущего у каждого тоже разное. Кто-то не ощущает вообще и с пеной у рта будет "доказывать" что это несущественно. А другие так остро ощущают, что не видят разницы было оно или нет, хотя оно может вообще никогда не случится.

И вот это каша в голове, что есть восприятие и ощущение, что есть существенно и касается в рамках поставленных задач, а что есть общее положение вещей в природе, как всё связано и как эти связи разделяются и т.п. Вот в эту игру разделение пониманий и сущностей не каждый играет, и соответственно не может воспринять и увидеть.
Да боже мой, многие даже не понимают смысла так называемого "спора".
Природная боязнь сложностей, будь она неладна.
10 янв 14, 13:45    [15396456]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
Lily V.
Member

Откуда: Магнитогорск
Сообщений: 92
Mnior
Lily V., прошу вас хоть как написать ваше восприятие почему BETWEEN проще.

Я неправильно выразилась. Нет никакой разницы и простоты в написании BETWEEN против ">= и <". Субъективность восприятия операндов, эмоции при построении запросов - это уже вообще за гранью:) Разумеется, все зависит от задачи.

Mnior
Lily V.
Лично для себя я сразу же оценила предпочтение использования. у нас сейчас как раз подобная ситуация, о которой предупреждал Minor.
Не лично вам сказано, но это восприятие будущего у каждого тоже разное.

Ну тут скорей речь не про "восприятие будущего", а про правильное проектирование, если можно предусмотреть что-то заранее, лучше это сделать заранее.
10 янв 14, 14:16    [15396711]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
~
Lily V.,
А почему бы тогда "between" не оставить, задав время для конца диапазона?
А не получится.
Lily V.
предлагаю уже эту тему - "за" и "против" использования BETWEEN.. - закрыть
А в том то и дело, что вот эти "за"/"против" притянуты за уши.
И у темы нет такого свойства как "закрыть тему". Мы тут никого не заставляем.
Не хотишь понять человека, ну и не продолжай беседу. Опять же не вам Lily V. лично сказано а в общем:
Если кто-то не хочет понять человека, ну пусть тогда не продолжает беседу.
10 янв 14, 14:20    [15396749]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
~
Guest
Mnior,
Может туплю, но что тут не получится?
between '20130101' and '20130101 23:59:59.999999'
10 янв 14, 14:45    [15397001]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
~
Guest
Mnior,
За ссылку спасибо, чуть позже ознакомлюсь.
10 янв 14, 14:46    [15397020]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
+ Lily V.
Lily V.
Нет никакой разницы и простоты в написании BETWEEN против ">= и <".
Нет, почему - всё есть. Но просто она не в том чем может показаться на первый взгляд. А гуманитарии много делают согласного "первого взгляда".
А вот напишите мне сходу BETWEEN по месяцу для февраля 2000 года и 1900. Просто?
Ну и как вы поняли, если есть время то порой это вообще невозможно и BETWEEN не работает вообще.
Lily V.
Субъективность восприятия операндов, эмоции при построении запросов - это уже вообще за гранью :)
За гранью ? Вы хотите сказать что когда мы друг друга слушаем мы не учитываем это?
Lily V.
Нет никакой разницы и простоты в написании BETWEEN против ">= и <". Субъективность восприятия операндов, эмоции при построении запросов - это уже вообще за гранью:) Разумеется, все зависит от задачи.
Это я не понял.
BETWEEN не удобен для всей ситуации в целом. При простом восприятии оператора вне контекста любой задачи, во всём его многообразии он вытесняется практически полностью (в использовании в MSSQL). И после нет никакой связи его вспоминать вообще.
Но даже если не пытать его воспринять (его положение в системе) он всё равно не удобен из-за обязаловки вычислять конец диапазона.
Lily V.
Ну тут скорей речь не про "восприятие будущего", а про правильное проектирование, если можно предусмотреть что-то заранее, лучше это сделать заранее.
Вы понимаете что это тоже неточно или неправильно в зависимости от ситуации.
Всё заранее предусматривать не надо.
Всё намного сложнее описывается. И я уверен что далеко не каждый это детально воспринимает.
Lily V.
Ну тут скорей речь не про "восприятие будущего"
Про него тоже речь. Нельзя это опускать при восприятии собеседника и самоконтроле.
10 янв 14, 18:29    [15398746]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
OlM
Guest
Lily V.,

Порверьте, я с вниманием выслушиваю альтернативные точки зрения. Но я всегда прошу их обосновать и всегда интересуюсь качеством аргументации. А уж когда мне говорят об ошибке в моем коде...

Ошибки в программировании можно поделить на следующие группы:
1) Орфографические и синтаксические ошибки, которые отлавливаются еще компилятором
2) Логические ошибки, приводящие к краху во время исполнения кода (деление на ноль и т.п.)
3) Логические ошибки, в частных случаях приводящие к неправильному результату
4) Ошибки performance'а (назовем их так), приводящие к неоправданному перерасходу ресурсов и/или увеличению времени выполнения
5) Ошибки, приводящие к проблемам при дальнейшем сопровождении и/или развитии
6) Прочие ошибки "гуманитарного" свойства (ну, здесь куча всякого-разного - от неудобного UI до игнорирования особо ценного мнения непосредственного начальника)

Я надеюсь, Вы согласитесь, что для серьезного обсуждения пятой и шестой групп ошибок в моем коде ни Вы, ни Mnior не обладаете необходимым знанием предметной области. Утверждение "если техзадание изменить, то работать не будет" вообще не является сколько-нибудь значимым - для любого кода можно найти такое изменение техзадания, которое сделает этот код неработающим. Вопрос в том, насколько вероятно такое изменение. И вот тут, когда Вы вслед за Mnior'ом говорите: "А Вам OIM прислушаться бы, а не спорить с пеной у рта... Откуда Вам знать?" я просто пожимаю плечами. И невольно отвечаю встречным вопросом: а что, собственно, заставляет Вас думать, что я не знаю свою предметную область?

Я надеюсь, Вы также согласитесь, что из оставшихся четырех групп любая ошибка может быть продемонстрирована экпериментально. Беда в том, что продекларировав ошибку в коде с BETWEEN, уважаемый Mnior не справился с задачей демонстрации этой ошибки (да, собственно, и не мог в принципе, потому что такого рода ошибки в приведенном коде просто нет).

Но и это не главная беда. Главная беда в том, что конкретный пример по исходной теме обсуждения, когда применение CASE в WHERE помогло оптимизатору построить план для очень частного, не спорю, но вполне жизненного случая, был, в общем-то, проигнорирован.

P.S.
А за дельные советы я всегда благодарю. Даже в этой ветке. И даже Mnior'а )) Ключевое слово - дельные.
18 янв 14, 02:50    [15432905]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
OlM
Но я всегда прошу их обосновать и всегда интересуюсь качеством аргументации.
... Mnior не справился с задачей демонстрации этой ошибки
Мне кажет проблема в том что для адекватности нужна взаимность / симметричность.
Вы привели пример 15267320, к которому вы получили 15268103 просто кучу "особенностей".
Но после того как вы придрались, что не вы не понимаете моего объяснения про BETWEEN (который был просто меленьким незначительным комментарием), вы продолжаете утверждать:
OlM
Но и это не главная беда. Главная беда в том, что конкретный пример по исходной теме обсуждения, когда применение CASE в WHERE помогло оптимизатору построить план для очень частного, не спорю, но вполне жизненного случая, был, в общем-то, проигнорирован.
Простите меня, но я не вижу тут признаков адекватности.
OlM
Вы согласитесь, что для серьезного обсуждения пятой и шестой групп ошибок в моем коде ни Вы, ни Mnior не обладаете необходимым знанием предметной области.

Синдром вахтёра? Вас продолжает возмущать что я "забазарился" на тотальную универсальность выводов.
Да, лять, именно. А всё от ошибки что "уровень понимания не может сильно отличаться".
Не надо переворачивать ситуацию. Тут всё банально:
1. "Тотальный" вывод
2. Его доказательство.
3. Оппонент, который пытается показать исключение.
Нас просто не интересует ваше "превосходящее" положение в "знании примера". Это ваша задача опровергнуть очень общий аргумент, показывая все стороны примера.
А пока ситуация сводится к тому, что вы сами не понимаете есть исключение из правила или нет.
Вы не можете понять доказательство и вы не можете доказать обратное.
А если дальше будет финт "я знаю но не скажу" - то как остальными будет воспринято? Правильно, просто проигнорируют и аргумент останется "тотальным" (якобы кроме вас одного).
OlM
И невольно отвечаю встречным вопросом: а что, собственно, заставляет Вас думать, что я не знаю свою предметную область?
На самом деле я так и не понял точно что вы хотите сказать.
Но дело, как я понимаю, что проблема в том что вы не до конца понимаете применимость того или иного в вами приведённом случае.
OlM
Утверждение "если техзадание изменить, то работать не будет" вообще не является сколько-нибудь значимым

Вы продолжаете манипулировать? Вам пытаются показать разные точки зрения, и как логику и как гуманитарию, или ещё абы как.
Пытаясь показать проблему всеобъемлюще. Так нет, вы ищите одно единственное красивое объяснение, которые побъёт сразу все явные и не явные "аргументы".
Мне не очень интересует значимость конкретного из всех аргументов для вас лично. Приверженность к типам аргументам мы можем только догадываться.
OlM
Вопрос в том, насколько вероятно такое изменение.
Я пытался вам объяснить, что дело не сколько в вероятности, а в несиметичности ситуации.
Что для одного случая (BETWEEN) есть влияющий фактор (смена ТЗ), а на другой (>= & <) - этот фактор не влияет, вообще.
И ни уровень вероятности, ни субъективность его значимости не может никак на это влиять, вообще.
И тем более не может быть аргументом против.

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

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

Но вы должны понять главное.
Из того что даже если существуют какие либо аргументы (объективные или субъективные), которые показывают эквивалентность в частном случае по некоторым частным факторам, то это не доказывает осмысленность и применимость обоих случаев. Ибо существуют аргументы как для этого случая (пусть даже субъективно не важные для вас) и другие случаи с объективными аргументами.
Что одного лишь того что в каком-то случае "эквивалентно", это не даёт повода его использовать. Хотя бы лишь потому, что для разработчика (а не человека который знает только один случай в жизни), который решает разные задачи, важны общность аргументов и наполнения себя правильными подходами. А точнее что знание альтернативного подхода, который не имеет никаких преимуществ - просто мешает, и просто бессмыслен.

И вы не акцентируйтесь на одном аргументе, который можно "удобно повернуть в свою сторону".
Хотя бы прокоментируйте на счёт аргумента, что для BETWEEN необходимо дополнительно рассчитывать дату конца.
Т.е. из-за того что данные дискретны, мы должны от подхода:
D >= T1 AND D < T2
D >= T2 AND D < T3
перейти к подходу:
D >= T1 AND D <= (T2-d)
D >= T2 AND D <= (T3-d)
???
Где ваш ответ на это? Вы (или кто либо в вашей системе) разве не должны рассчитывать это?
С (>= & <) этого не нужно, разве что дизайнеру интерфейса.
Это субъективно?
OlM
Вы также согласитесь, что из оставшихся четырех групп любая ошибка может быть продемонстрирована экпериментально.
Не любая. К примеру на 4й пункт может быть несостыковки оппонентов в понимании что есть "неоправданному перерасходу ресурсов".
А во вторых, в ваших "пунктах" совершенно не освещено проблематика разрабоки продукта, правильности понимания первоначального ТЗ, правильности постановки ТЗ, пониамния используемых инструментов и их роли, правильность выбора инструментов, его применимость, покрытие инструментом предметной области моделирования и прочие "высокие материи".
OlM
А за дельные советы я всегда благодарю. Даже в этой ветке. И даже Mnior'а )) Ключевое слово - дельные.
Проблема в том что на сколько вы можете увидеть эту "дельность".
А сдругой, если придираться, подчёркивание слова "дело", вы не задаёте вопросов выше чем это. В итоге теряя некоторые ключевые точки видения ситуации.
Это я снова и снова к вопросу выбора "заострить внимание на скорости бега или на правильность направления".

Повторяю, мы все свободно переживём если вы будете ошибаться. Или я буду. Тут важнее на сколько хорошо и полно описана ситуация здесь на форуме. Ибо это видят все. Ибо все будут это применять к своим задачам. И совершенно не важно на сколько вы будете правы для себя, или я для себя - если аргументация не будет выложена здесь для всех.
18 янв 14, 14:11    [15433459]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
OlM
для любого кода можно найти такое изменение техзадания, которое сделает этот код неработающим
Mnior
Что для одного случая (BETWEEN) есть влияющий фактор (смена ТЗ), а на другой (>= & <) - этот фактор не влияет, вообще.
Придумайте такой объективный фактор, при котором на BETWEEN он не повлияет, но на (>= & <) повлияет.

Давайте вы будете последовательны в рассуждениях.
18 янв 14, 14:17    [15433474]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
OlM
Guest
Mnior,

Вы пишете так много всего, что жизни не хватит ответить на каждый Ваш постулат. Я выбрал наиболее важный для меня - Ваше громогласное заявление, что у меня в коде ошибка. Такое заявление у меня всегда вызывает только одну реакцию - заявитель должен сделать что-то одно:
1) или доказать сказанное (специально для "технарей" напоминаю - ошибки от 1-го до 4-го рода могут, а значит должны быть продемонстрированы скриптами);
2) или извиниться;
3) или пойти в задницу.
Ни первое, ни второе Вами так и не сделано.

Теперь по некоторым другим Вашим аргументам.
Mnior
Не надо переворачивать ситуацию. Тут всё банально:
1. "Тотальный" вывод
2. Его доказательство.
3. Оппонент, который пытается показать исключение.
Нас просто не интересует ваше "превосходящее" положение в "знании примера". Это ваша задача опровергнуть очень общий аргумент, показывая все стороны примера.

Нет, не так. Я нигде не утверждал, что Ваш вариант не работает. Это Вы утверждали, что в моем варианте ошибка. Поэтому бремя доказательств - на Вас.
Mnior
Хотя бы прокоментируйте на счёт аргумента, что для BETWEEN необходимо дополнительно рассчитывать дату конца. ... Где ваш ответ на это? Вы (или кто либо в вашей системе) разве не должны рассчитывать это?

Коментирую и отвечаю: этот аргумент - полная чушь, все с точностью до наоброт. В нашем варианте (квантование по дням) для BETWEEN не надо рассчитывать дату конца. Если юзеру нужны данные с 1 по 31 декабря, то он и вводит именно эти две даты: 1 декабря 2013 и 31 декабря 2013. И запрос исполняется как BETWEEN '20131201' AND '20131231'. А теперь подумайте, как дело будет обстоять при варианте >= and <. Вы либо юзера должны будете заставлять вводить 1 января 2014 вместо 31 декабря 2013 (и попробуйте этим юзверям объяснить, при чем тут 2014 год, если им нужен декабрь 2013-го), либо сами должны вычислять нужную дату.
Mnior
Придумайте такой объективный фактор, при котором на BETWEEN он не повлияет, но на (>= & <) повлияет.

Зачем? Я что, где-то утверждал универсальный характер BETWEEN и его великую сакральную ценность? Всякое решение уместно в своем конкретном случае. Ирония, однако, в том, что Ваш аргумет о возможности изменения техзадания в нашем случае тоже не работает - читайте дальше.
Mnior
Я пытался вам объяснить, что дело не сколько в вероятности, а в несиметичности ситуации.
Что для одного случая (BETWEEN) есть влияющий фактор (смена ТЗ), а на другой (>= & <) - этот фактор не влияет, вообще.

Т.е. Вы пытались рассказать мне об ошибке пятого рода. Хорошо, примем это как версию, хотя первоначально Вы говорили совсем о другом - о проблемме выколотой точки.
Так вот, если говорить о выживании кода в случае изменения техзадания, то в нашем случае BETWEEN выживет и в случае перехода на даты+время. Более того - и переписывать на стороне сервера не нужно будет ровным счетом ничего. Потому что и в этом случае в нашей системе время будет квантовано - но уже по секундам, и принципиально не поменяется НИ-ЧЕ-ГО. А юзер будет вводить даты 1 декабря 2013 0:00:00 и 31 декабря 2013 23:59:59. И все это при условии, что мы забыли - такого перехода просто не будет.

Кстати, Lily V., вполне возможно, что посекундное квантование - это решение и для Вас.
Mnior
Не любая. К примеру на 4й пункт может быть несостыковки оппонентов в понимании что есть "неоправданному перерасходу ресурсов".

Согласен, здесь возможен субъективизм, если разницы в выходных параметрах будут разнонаправленными. Но здесь, по крайней мере, можно говорить с цифрами в руках.
Mnior
А во вторых, в ваших "пунктах" совершенно не освещено проблематика разрабоки продукта, правильности понимания первоначального ТЗ, правильности постановки ТЗ, пониамния используемых инструментов и их роли, правильность выбора инструментов, его применимость, покрытие инструментом предметной области моделирования и прочие "высокие материи".

Это все в пунктах 5 и 6. Для конкретного разговора по этим пунктам нужно, чтобы все собеседники были в теме, это же очевидно. Или Вы готовы всерьез обсуждать здесь правильность Вашего понимания ТЗ? Обсуждать это с публикой, которая Вашего ТЗ и в глаза не видела? Что-то сомневаюсь.
Mnior
OlM
Но и это не главная беда. Главная беда в том, что конкретный пример по исходной теме обсуждения, когда применение CASE в WHERE помогло оптимизатору построить план для очень частного, не спорю, но вполне жизненного случая, был, в общем-то, проигнорирован.

Простите меня, но я не вижу тут признаков адекватности.

Вы много чего не видите... Здесь и здесь я пытаюсь донести до вас простую мысль: существуют ситуации, когда применение CASE в WHERE оправдано. Ваша реакция на приведенный пример была: оптимизатор "случайным образом делает линейный план... Но CASE в данном случае конкретно не причём". Ну, что сказать... Можно, конечно, верить, что поведение оптимизатора управляется положением звезд, но я эту точку зрения почему-то не разделяю. В качестве альтернативы я предположил, что поведение оптимизатора объясняется тем, что для случаев с CASE'ом и без него оптимизатор ожидает различное количество возвращаемых записей, поэтому таблицы джойнятся оптимизатором по-разному в зависимости от того, какой синтаксис фильтра мы выберем - с CASE'ом или без. Никакого обсуждения этого предположения так и не последовало.

Впрочем, наверное уже и не надо - мне откровенно наскучил разговор с Вами, Mnior, уж простите. А все желающие проверить сказанное на практике могут сделать это самостоятельно, на своих данных.
18 янв 14, 19:15    [15434094]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
OlM
Кстати, Lily V., вполне возможно, что посекундное квантование - это решение и для Вас.
Не решение, уже приводил ссылку выше что не работает это в скуле. Читайте спойлер.
+ Про BETWEEN
OlM
Так вот, если говорить о выживании кода в случае изменения техзадания, то в нашем случае BETWEEN выживет и в случае перехода на даты+время.
Не выживет, выше 15396749 давал ссылку, что из-за особенностей внутреннего представления и многих других факторов оно не работает всегда и BETWEEN даёт "неожиданно" неверные результаты. Не поленитесь пойти по ссылке и убедится.
OlM
Mnior
Хотя бы прокоментируйте на счёт аргумента, что для BETWEEN необходимо дополнительно рассчитывать дату конца. ... Где ваш ответ на это? Вы (или кто либо в вашей системе) разве не должны рассчитывать это?
Коментирую и отвечаю: этот аргумент - полная чушь, все с точностью до наоброт. В нашем варианте (квантование по дням) для BETWEEN не надо рассчитывать дату конца. Если юзеру нужны данные с 1 по 31 декабря, то он и вводит именно эти две даты: 1 декабря 2013 и 31 декабря 2013.
Это означает что пользователь рассчитывает дату конца, а не программист.
Вы с этим не согласны? Т.е. вместо того чтобы указать просто месяц, ему разве не приходится вычислять последнюю дату?
И да, если я скажу "дайте мне данные с 5 по 7" почему вы решили что по 7е включительно?
А если я скажу, дайте мне данные за февраль 1900 года, что вы будете делать?
Так что ваши утверждения что "не нужно" схоластика чистой воды.
Более тего, это дополнительно может приводить к ошибкам. Пользователь ошибся (ввел 30 к примеру), и потратил кучу времени в поисках пропавших документов, или несходимости сумм и т.п.
OlM
А теперь подумайте, как дело будет обстоять при варианте >= and <. Вы либо юзера должны будете заставлять вводить 1 января 2014 вместо 31 декабря 2013 (и попробуйте этим юзверям объяснить, при чем тут 2014 год, если им нужен декабрь 2013-го), либо сами должны вычислять нужную дату.
Вы специально пропускаете что я писал выше? Скорее да.
Я писал о дизайнере интерфейсов.
Нормальный дизайнер знает где и как нужно делать. Если там нужно указать год, квартал, или месяц, то пользователь не будет вводить ни 1е ни 31. Если имеется ввиду включительно или нет, справа или слева, в зависимости от нужд, дизайнер (точнее с разработчиком UI на пару) определит это и переведёт на в точные и жёстко определённые и не двусмысленные понятия.
Или вы предпочитаете чтобы эта неопределённость доходила до отдел кодирования?
Или вы хотите что бы в ТЗ во внутренней документации и в заданиях был зоопарк?
Чтобы переходя от заказчика по кодера по всем инстанциям было несколько вариантов допущения этого двусмыслия?
Посему ваш комментарий пролетает. Как опровержение что считать ничего не нужно.
OlM
Mnior
Придумайте такой объективный фактор, при котором на BETWEEN он не повлияет, но на (>= & <) повлияет.
Зачем? Я что, где-то утверждал универсальный характер BETWEEN и его великую сакральную ценность?
Вы специально забываете откуда возник данные вопрос и на что он был приведён?
Да, вы утверждаете что BETWEEN имеет хоть какое-то объективное преимущество перед (>= & <) для типа данных время.
И не надо подмены понятий, я спрашивал хотя бы частный пример.
Но ни разу ни один не привели. Следовательно моё доказательство бессмысленности BETWEEN в данном вопросе пока верно.
OlM
... и принципиально не поменяется НИ-ЧЕ-ГО. А юзер будет вводить даты 1 декабря 2013 0:00:00 и 31 декабря 2013 23:59:59.
Помимо того что не будет работает, вы хотите перевалить это на пользователя?
- Вы же утверждали что пользователь ничего дополнительно не считает?!
- Вы хотите что бы пользователь вводил это руками?
- Вы хотите что бы пользователь изменил свою привычку из-за внутренних решений разработчиков или совершенно другого отдела предприятия?
- Вы утверждаете что UI контролы волшебным образом расширятся и позволят вводить время?
- Вы утверждаете что ранее они вводили явно 31 декабря 2013 00:00:00 и притом без задней мысли?
Вы вообще адекватны?!
А как же код в других частях программы, в отчётах там или ещё где в логике кода, которая вычисляла конец периода (за месяц, неделю, год и т.п). Там что не надо переписать, добавив приписку ' 23:59:59.999' ? (которая не всегда работает верно)
Вы поймите, вы вводите насильно такое понятие как "квантование". Дополнительный надуманный фактор.
И разница в том что BETWEEN чувствителен к этому фактору, в то время как (>= & <) совершенно этот фактор не нужен, он для него бессмыслен (симулякр) и следовательно никак не влияет.
Зачем забивать себе голову этой чушью?

Борьба с ветряными мельницами, сами ввели сами и боремся с ней.
+ Про CASE
OlM
я пытаюсь донести до вас простую мысль: существуют ситуации, когда применение CASE в WHERE оправдано.
1. Простую? На основании чего простую что "Всё возможно"?!
2. Вы то пытаетесь, что похвально, но пока у других это получалось по лучше. (и я ответил на те существенные аргументы, хотя они не про CASE именно в WHERE)
OlM
Ваша реакция на приведенный пример была
Вы написали "реакция", потому что вам важен общий эмоциональный фон, как важный фактор? Может всё-таки вы обдумаете и поймёте приведённые там аргументы, и ответите на ключевые из них?
OlM
Можно, конечно, верить, что поведение оптимизатора управляется положением звезд, но я эту точку зрения почему-то не разделяю.
Я писал про звёзды или вы насмехаетесь? Я что совсем не аргументировал. Или вы опять включаете режим "авторитетности"?
OlM
А все желающие проверить сказанное на практике могут сделать это самостоятельно, на своих данных.
Лолшто?
Что проверить на практике?

Максимум что вы сделали, вы привели глючный план в вакууме.
При этом написали:
OlM
Как я понимаю, сама логика фильтрации в моем запросе действительно запутывает оптимизатор, и в этом главная трудность.
Более того, я никогда и не задумывался о симметричности условий, а это серьезное упущение. Спасибо. Значит я уже не напрасно влез в разговор.
При этом я довольно подробно расписал основные проблемы запроса и как надо подходить к его решению 15273642 и 15292426.
Но в ответ началось:
OlM
Если не возражаете, я сегодня отвечу в расслабленно-философском стиле, без конкретики


Вы все-таки или покажите что решение именно в CASE, а не того фактора что я привёл.
Или покажите вариант который каждый может запустить и увидеть.
OlM
В качестве альтернативы я предположил, что поведение оптимизатора объясняется тем, что для случаев с CASE'ом и без него оптимизатор ожидает различное количество возвращаемых записей, поэтому таблицы джойнятся оптимизатором по-разному в зависимости от того, какой синтаксис фильтра мы выберем - с CASE'ом или без. Никакого обсуждения этого предположения так и не последовало.
Чего-чего?
1. Это я ушёл от разговора? Это вы 15294785 ушли. Или я что-то пропустил? Ну так тыкните.
2. Какое вам дело до ваших предположений? Вы хотите что бы я доказывал ваше предположение, как контр-ответ на мои утверждения?
Как? Если я этого не вижу.
И я согласился поковыряться в вашем предположении сам 15292426:
Mnior
Для начала надо было показать реальный план запроса, а не предположительный
Но никакой реакции не последовало!
+ OlM и прихология (offtop)
OlM
Вы пишете так много всего, что жизни не хватит ответить на каждый Ваш постулат.
Это повод не отвечать на важдные вопросы?
Это повод пропускать чтение (частично или полностью и невнимательно - не важно) моих постов? Чтобы снова и снова возвращаться к тем же вопросам?
OlM
Я выбрал наиболее важный для меня - Ваше громогласное заявление, что у меня в коде ошибка.
Всё-таки вы хотите продолжать гнуть свою линию с подменом понятий. Зачем?
Может вы меня не поняли? Почему вы отметаете этот вариант?
Ну коль предпосылка не верна (что "ошибка в коде", как расширение понятия) то и всё остальное отметается автоматически.

Я не говорил что в коде синтаксическая ошибка или что код не возвращал ожидаемый результат в некоторых случаях.
Вы лжоте.
OlM
Я нигде не утверждал, что Ваш вариант не работает. Это Вы утверждали, что в моем варианте ошибка. Поэтому бремя доказательств - на Вас.
Я доказал (что подход бесполезен, а не ошибка в коде). Вам оно не понравилось. Где не понравилось - непонятно. А коль непонятно, значит мне остаётся только умыть руки.
Вы утверждаете что я имел другое ввиду, когда просто вы не так меня поняли. Это я вам заявлял много раз - вы не принимаете и не реагируете. Опять остаётся умыть руки.
Вместо того чтобы перестать заниматься этой чушью, и попытаться понять о чём же всё же говорит оппонент, что он хочет донести, нет вы продолжаете к этому возвращаться.
Давайте больше не возвращаться к этому. Ок?
OlM
Mnior
Я пытался вам объяснить, что дело не сколько в вероятности, а в несиметичности ситуации.
Что для одного случая (BETWEEN) есть влияющий фактор (смена ТЗ), а на другой (>= & <) - этот фактор не влияет, вообще.
Т.е. Вы пытались рассказать мне об ошибке пятого рода. Хорошо, примем это как версию, хотя первоначально Вы говорили совсем о другом - о проблемме выколотой точки.

А разве "проблема выколотой точки" не касается "смены ТЗ"? Она же её затрагивает прямым образом.
Я приводил несколько разных аргументов, а не только одну цепочку аргументации. А приводил вам со всех сторон, чтобы хоть как-то вам втолковать.
Так что не надо этих профанаций.
OlM
Но здесь, по крайней мере, можно говорить с цифрами в руках.
Толку-то. Я уже "спорил" здесь на форуме, о правильной интерпретации цифр. Принципиально упёртые как вы всё равно будут говорить что их вариант верен, а оппонента полностью неверен и не имеет здравого зерна.
OlM
Mnior
А во вторых, в ваших "пунктах" совершенно не освещено проблематика разрабоки продукта, правильности понимания первоначального ТЗ, правильности постановки ТЗ, пониамния используемых инструментов и их роли, правильность выбора инструментов, его применимость, покрытие инструментом предметной области моделирования и прочие "высокие материи".
Это все в пунктах 5 и 6. Для конкретного разговора по этим пунктам нужно, чтобы все собеседники были в теме, это же очевидно. Или Вы готовы всерьез обсуждать здесь правильность Вашего понимания ТЗ? Обсуждать это с публикой, которая Вашего ТЗ и в глаза не видела? Что-то сомневаюсь.
1. Это нет ни одном вашем пункте. Во всяком случае явно. Ибо разработка это не только дальнейшее сопровождение, UI и психология.
2. А специально то привёл, как не подходящее вашему духу, духу мыслить только в частном порядке.
3. Сомневаетесь потому что вы меряете по себе. А есть люди, (я по отношении к вам) которые имеют смелость рассуждать и обсуждать обобщённо и абстрактно. Обладая для этого необходимым логическим аппаратом.
Почитайте о типах личностей. На злобу дня статья на хабре.

OlM
Впрочем, наверное уже и не надо - мне откровенно наскучил разговор с Вами, Mnior, уж простите.
Никто вас не заставляет.
1. Ваш случай рассматривался как контр пример осмысленности BETWEEN. Он ничего не доказал - следовательно BETWEEN бессмыслен, для типа время. Ну и ладно.
2. Вы пытались привести контр аргумент по CASE, на который были ответы и даже вы согласились что не учитывали симметричность формулы (не эквивалентность выражений и их обратного). И даже после этого я остался открыт для докопания вашего случая до конца. Но от вас не последовало никакой реакции. Ну и ладно.

Не вы одни во вселенной, может ктось другой попытается найти пример.
И задачи есть более сложные и не находятся на них ответы тысячелетиями. Это же не трагедия. Всё нормально.
19 янв 14, 00:57    [15435252]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
OlM
Guest
Как же все запущено...
Mnior
OlM
Кстати, Lily V., вполне возможно, что посекундное квантование - это решение и для Вас.

Не решение, уже приводил ссылку выше что не работает это в скуле. Читайте спойлер.

Lily V., Вам только что пытались сказать неправду. Mnior или снова не понял о чем речь, или все еще находится в плену "сверхценной идеи".

Пример, на который ссылается Mnior, никакого отношения к квантованым данным не имеет - он очень наглядно демонстрирует проблему "выколотой точки" на неквантованом времени. Я же предлагаю Вам не отказываться от квантования, которое полностью снимает пресловутую проблему "выколотой точки". Вы уже применяли суточное квантование. Теперь вместо суточного шага квантования вы можете перейти на секундный шаг, или на минутный шаг - зависит от Вашего ТЗ. Когда Вы хранили даты без временной составляющей, т.е. когда Вы принудительно обнуляли часы, минуты и т.д. Вы тем самым квантовали даты посуточно. Теперь же, просто записывайте Ваши даты в таблицу обнулив уже не всю "временную" компоненту, а только доли секунд. И все у Вас будет работать, и запросы с BETWEEN переписывать не понадобится. Да, юзерам придется вводить даты с временем (другое дело, как это будет организовано - с автоподстановкой дефолтных 0:00:00 и 23:59:59 или с помощью таблиц стандартных периодов, или как-то еще), но это уже неизбежно, причем неизбежно вне зависимости от того, какой вариант Вы выберете - иначе ни к чему и сам переход на новые правила.

Но еще раз - все это только если Ваше новое ТЗ допускает секундное квантование. Если нет - тогда да, тогда по варианту Mnior'а.

Теперь по CASE в WHERE.
Утверждается и предлагается к самостоятельной проверке на ваших данных следующее:
1. Для двух нижеследующие вариантов запроса оптимизатор всегда строит планы идентичные во всем, кроме ожидания количества возвращаемых записей:

DECLARE @ID1 INT
SET ID1 = ...

-- Version 1

SELECT *
FROM dbo.Table1 AS T1
WHERE T1.ID = @ID1 OR @ID1 = 0

-- Version 2

SELECT *
FROM dbo.Table1 AS T1
WHERE T1.ID = CASE WHEN @ID1 = 0 THEN T1.ID ELSE @ID1 END

--  Примечание: все упомянутые поля в таблицах должны быть - NOT NULL


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

DECLARE @ID1	INT
,	@ID2	INT
,	@ID3	INT
,	@ID4	INT

SET ID1 = ...
SET ID2 = ...
SET ID3 = ...
SET ID4 = ...

-- Version 1

SELECT *
FROM		dbo.Table1	AS	T1
INNER JOIN	dbo.Table2	AS	T2	ON	T2.ID	= T1.ID2
INNER JOIN	dbo.Table3	AS	T3	ON	T3.ID	= T2.ID3
INNER JOIN	dbo.Table4	AS	T4	ON	T4.ID	= T1.ID4

WHERE (T1.ID = @ID1 OR @ID1 = 0)
AND (T2.ID = @ID2 OR @ID2 = 0)
AND (T3.ID = @ID3 OR @ID3 = 0)
AND (T4.ID = @ID4 OR @ID4 = 0)

-- Version 2

SELECT *
FROM		dbo.Table1	AS	T1
INNER JOIN	dbo.Table2	AS	T2	ON	T2.ID	= T1.ID2
INNER JOIN	dbo.Table3	AS	T3	ON	T3.ID	= T2.ID3
INNER JOIN	dbo.Table4	AS	T4	ON	T4.ID	= T1.ID4

WHERE T1.ID = CASE WHEN @ID1 = 0 THEN T1.ID ELSE @ID1 END
AND T2.ID = CASE WHEN @ID2 = 0 THEN T2.ID ELSE @ID2 END
AND T3.ID = CASE WHEN @ID3 = 0 THEN T3.ID ELSE @ID3 END
AND T4.ID = CASE WHEN @ID4 = 0 THEN T4.ID ELSE @ID4 END

3. Разница в планах выполнения в п.2, когда она существует, объясняется разницей в планах п.1
4. Практический вывод: планы, которые оптимизатор строит для вариантов с CASE для данного частного типа запросов - предпочтительнее.
5. Следовательно есть ситуации, когда CASE в WHERE оправдан.
6. Следовательно самый правильный совет в этой ветке дал MasterZiv:
MasterZiv
Нет такого правила "нельзя". Есть другое правило: "Думай".

Mnior, это, кстати, и для Вас полезный совет, он работает заметно лучше, чем шаблоны, которые имеют свойство рваться.
19 янв 14, 22:34    [15437768]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
+ BETWEEN: Про маразм с квантованием
OlM
он очень наглядно демонстрирует проблему "выколотой точки" на неквантованом времени.
Ну вы не правы.
1. По ссылке не я демонстрирую. И это не важно кто.
2. Во вторых, "не-квантованных" типов данных в скуле нет. Значение занимает фиксированной объём памяти.
Да и про точность "квантования" - спорный момент. Хорошо ещё что в скуле нет секунды координации.
OlM
Я же предлагаю Вам не отказываться от квантования, которое полностью снимает пресловутую проблему "выколотой точки".
Эээ, тут немного двусмысленно звучит, "квантование" снимает проблему, или "отказ" от квантования? Видимо второе.
Тогда недвусмысленно звучит что: OlM советует не снимать проблему.
Но "квантовние" не есть проблема, оно всегда присутствует, проблема в использовании BETWEEN для решения задачи с диапазонами.
OlM
Теперь вместо суточного шага квантования вы можете перейти на секундный шаг, или на минутный шаг - зависит от Вашего ТЗ.
Ну в скуле нет ни минутного шага ни секундного.
И добиваться хранить в данных единицах просто банально идиотизм. Писать при каждом генерировании/получении/конвертации/преобразованиях данных приведение к "кванту" - это уже клиника. И только ради BETWEEN? Который ничего кроме проблем не даёт.

OlM
Когда Вы хранили даты без временной составляющей, т.е. когда Вы принудительно обнуляли часы, минуты и т.д.
Не думаю что кто-то принудительно что-то обнулял. Неявно - может быть, а отчасти брал данные в соответствующем типе.
OlM
просто записывайте Ваши даты в таблицу обнулив уже не всю "временную" компоненту, а только доли секунд. И все у Вас будет работать, и запросы с BETWEEN переписывать не понадобится.
Переписать другую часть кода, лишь бы оставить BETWEEN, при этом возможно нарушив другие части ТЗ. Увеличив шанс на появление новых багов, засрав систему ещё больше.
OlM
с автоподстановкой дефолтных 0:00:00 и 23:59:59 или с помощью таблиц стандартных периодов, или как-то еще
О да, пресловутое "переписывать ничего надо будет вообще".
OlM
все это только если Ваше новое ТЗ допускает секундное квантование. Если нет - тогда да, тогда по варианту Mnior'а.
До последней капли крови!!!
Так что оставить BETWEEN как есть - это худший совет.

OlM, прокомментируйте это пожалуйста:
Mnior
Вы поймите, вы вводите насильно такое понятие как "квантование". Дополнительный надуманный фактор.
И разница в том что BETWEEN чувствителен к этому фактору, в то время как (>= & <) совершенно этот фактор не нужен, он для него бессмыслен (симулякр) и следовательно никак не влияет.
Зачем забивать себе голову этой чушью?

Борьба с ветряными мельницами, сами ввели сами и боремся с ней.
+ Про CASE
OlM
WHERE (T1.ID = @ID1 OR @ID1 = 0)
AND (T2.ID = @ID2 OR @ID2 = 0)
AND (T3.ID = @ID3 OR @ID3 = 0)
AND (T4.ID = @ID4 OR @ID4 = 0)
Постойте, но вы же согласились 15282156 что несимметричность условия это серьёзное упущение.
OlM
2. Для двух логически идентичных запросов (см. ниже) оптимизатор иногда (при достаточном количестве JOIN'ов, при наличии индексов, при наличии достаточного количества записей) строит разные планы выполнения.
1. Условно идентичных. Логически они не идентичны, ибо логическая идентичность не связана с данными или их типами, на которых они собираются.
Они в этой частной ситуации возвращают эквивалентные данные.
2. Бла-бла-бла. Вы будете опять приводить допустим/предположим и т.п. Приведите работающий пример, а не занимайтесь подменом понятий.
Давайте уже ваши реальные данные/структуры/запросы, чтобы показать что там CASE не нужен.
OlM
3. Разница в планах выполнения в п.2, когда она существует, объясняется разницей в планах п.1
Эээ. Чего? Нет там разницы в планах в п.1. И не поэтому она объясняется.
Ваш шаблон рвётся об реальность, думать надо почему там выкручивается.
А если бы вы прислушались к советам, то смогли сильно улучшить выполнение вашего запроса.
OlM
4. Практический вывод: планы, которые оптимизатор строит для вариантов с CASE для данного частного типа запросов - предпочтительнее.
В том то и вся загвоздка. Что практически так не делается, для достижения реальных практических улучшений и повышения эффективности.
OlM
5. Следовательно есть ситуации, когда CASE в WHERE оправдан.
Не оправдан совершенно. Вы совершаете туже логическую ошибку что и с BETWEEN:
Если это даёт случайное приемущество в пару %% по скорости, это не доказывается что этот подход предпочтителен или оправдан. Ибо нормальное написание запроса даст:
1. Сильно вероятно, что намного большее преимущество, или
2. Будет более понятно и проще написан, но точно не хуже работать.
OlM, пожалуйста, прокомментируйте это.

+ OlM
Вот упёртый же. Социальная изворотливость важнее чем логическая правдивость.
Уже большой + в карму выживания. Согласен, быть честным это порок, слабое место.
Я уже хочу пожать вам руку за это. Серьезно.
И вообще почти все на вашей стороне, OlM. Борьба героя с монстром, а монстр, потому что избивает младенца. Какой психологический выкрутас однако. :) Шутка. Не принимайте близко к сердцу, мы же взрослые люди.
OlM
6. Следовательно самый правильный совет в этой ветке дал MasterZiv:
MasterZiv
Нет такого правила "нельзя". Есть другое правило: "Думай".
Mnior, это, кстати, и для Вас полезный совет, он работает заметно лучше, чем шаблоны, которые имеют свойство рваться.
Эээ, не вижу связи между использовать (>= & <) вместо BETWEEN и "не думай", скорее наоборот. Это яркий пример как шаблон BETWEEN порвался об реальность.
Поэтому последуйте совету. Думайте. Копайте и пытайтесь разобраться до конца.

Дело не запретах, никто не запрещает вам совать пальцы в розетку и хвататься за оголённые провода, просто это бессмысленно.
20 янв 14, 05:49    [15438570]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Mnior
2. Будет более понятно и проще написан, но точно не хуже работать.
Я бы даже смягчил бы это утверждение.

Лучше уж понимать и знать только правильные подходы и их придерживаться, т.к. они очень часто дают большие преимущества и очень мало незначительные недостатки и не забивать голову остальным, а в остальном додумывать,
Чем забивать множеством ложных или слабых "паттернов", которые изредка дают случайные малые приемущества, а частенько сильные недостатки, и перестать думать отрекаясь "и так сойдёт, не буду обдумывать".

Для CASE и BETWEEN (по тематике) это практически строгое выполнение.
Любые контр примеры приветствуются.

PS: И эта, я не запрещал использовать BETWEEN / CASE, а призывал использовать его обдуманно.
Так что "запрет" это надуманно и недопонимание.
20 янв 14, 06:04    [15438575]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
~
Guest
Mnior
Не решение, уже приводил ссылку выше что не работает это в скуле. Читайте спойлер.
...

Объективности ради, ссылка ни о чем. Из разряда Не подумали -> Сделали -> Не проверили.

автор доставляет
People also make incorrect assumptions about BETWEEN in that it doesn't matter which order the parameters are listed - e.g. BETWEEN 3 AND 5 and BETWEEN 5 AND 3 should yield the same answer.


Ахтунг не ужели программизд не знает во сколько заканчиваются сутки, чтобы написать такое для datetime2?
автор
SELECT OrderID, OrderDate     FROM dbo.Data    WHERE OrderDate BETWEEN '20110701' AND '20110731';
20 янв 14, 11:35    [15439342]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
invm
Member

Откуда: Москва
Сообщений: 9646
~
Ахтунг не ужели программизд не знает во сколько заканчиваются сутки, чтобы написать такое для datetime2?
автор
SELECT OrderID, OrderDate     FROM dbo.Data    WHERE OrderDate BETWEEN '20110701' AND '20110731';
И заказ, сделанный, например, в 20110731 00:00:01, в выборку не попадет...
20 янв 14, 11:59    [15439560]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
~
Guest
invm, это понятно, только какое отношение криворукость имеет к оператору between?
15397001
20 янв 14, 12:09    [15439665]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
~
Объективности ради, ссылка ни о чем. Из разряда Не подумали -> Сделали -> Не проверили.
В целом, для строгости, согласен.
Но вы найдёте на форуме темы, где не подумали, сделали, не проверили, пошли жаловаться на форум.
И вот смысл ходить по минному полю?
20 янв 14, 12:16    [15439746]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
~
Guest
Mnior,
ИМХО, between упрощает чтение сложных запросов с кучей условий, но не более того. И, да, напороться можно... но это не проблема данного оператора.
20 янв 14, 12:33    [15439928]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
В целом тип данных со временем так сделан, что есть "круглые" значения. Аля ровно секунда, минута и т.п.
Хотя в остальных случаях последний знак в отображаемом значении неточен / неверен.

К примеру, для типа DateTime, отображается
23:59:59.990
23:59:59.993
23:59:59.997

Казалось бы, между .993 .997 разница в 4 микросек. Но там дробное значение времени 1/300 сек.

И эти округления надо учитывать.

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

Мне прикалывает другое - психологический трюк:
Когда фактор "Ф" вообще не влияет для случая "А" и как-то влияет на случай "Б" - для одних из этого делается очевидный вывод, а для других "очевидно нехватает". А далее идёт "спор" о субъективности и важности проблем, видов влияний этого фактора.
Понимаю, если были другие бы факторы, которые влияли ровно наоборот. Но их нет.

Вот эту высокую абстрактность логического аппарата, постоянно наблюдаю - что для некоторых она не чувствуется вообще. А она является креугольным фактором выбора, быстрого выбора, правильного подхода, и помогает очевидно видеть ситуацию, когда без неё для этого надо сделать кучу сложных выводов.
20 янв 14, 12:54    [15440078]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
~, наконец кто-то стал говорить о преимуществах BETWEEN, а не пытаться бесполезно выкручиваться от его недостатков.
~
between упрощает чтение сложных запросов с кучей условий
Это субъективное мнение. Логически неверное.
Вы напишите эти кучу учловий, в одном случае и в другом и посмотрите беспристрастно.

Я скажу что (>= & <) проще и надёжнее воспринимать (для времени). Но вы не согласитесь. Просто не согласитесь, вы не сможете сказать почему. Хотя я могу формализовать почему лучше, а вы скорее нет. И это понятно, с такой логикой и слабой формализацией от вас требовать это бесполездно и глупо.
Лучше уж я это будут делать за вас.

WHERE	D.DateTime	>= @From
AND	D.DateTime	<  @To

WHERE	D.DateTime BETWEEN @From AND @To
В первом случае элементы диапазона стоят рядом, сразу видна разница между ними и лучше видны очепятки, а также чётко видны строгость равенства.
Во втором случае стоит раздельно. Можно "побороть", переместив AND на новую строку - но это будет путать, ибо тут AND не логический оператор между выражениями, а вторая часть оператора BETWEEN.
C другой стороны, вы скажете что если слева стоит сложное выражение, то и дублировать не надо.
На что я могу ответить:
1. Это даже приемущество - ещё один мешающий факторов писать неправильно, чтобы не нарваться по глупости для неиспользование индекса:
WHERE	D.DateTime	>= @From + 1 -- Индекс сработает
AND	D.DateTime	<  @To + 1

WHERE	D.DateTime - 1 BETWEEN @From AND @To -- Индекс не сработает

2. Как я писал много постов выше, ещё один фактор писать выражения в SELECT, что уменьшает ленивость приводящую к Copy&Past идентичных выражений.

~
но это не проблема данного оператора.
Проблема. Когда кучу факторов, хоть и скрыто для некоторого вида мышления и проявляется не так очевидно. Это не значит что у оператора нет проблем. Считайте это "проблемы другого рода".
Но всё равно, не чувствовать "логику факторов" - это имхо плохо.
20 янв 14, 13:14    [15440216]     Ответить | Цитировать Сообщить модератору
 Re: Возможно ли вписать CASE в условие WHERE  [new]
OlM
Guest
~,

Да тут дело даже не в BETWEEN - его можно вообще отменить и ничего не поменяется. Просто юзерам очень трудно объяснить принцип "включая один параметр и не включая второй". Если юзеру нужен период с 27-го по 31-е декабря 2013 года, его не заставишь указывать в качестве правого параметра 01/01/2014 - юзер просто не понимает, при чем тут следующий год. А если оработать включая оба, то с выколотой точкой действительно надо бороться. Вот и все.
20 янв 14, 13:14    [15440222]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить