BETWEEN............

Hmm eto neshto dosta interesno kak mislite dali BETWEEN val1 and val2 e po dobro ot select * from.... where col>val1 and col<val2
ima dosta interesni mnenia po vyprosa zavisimost ot tipa pri integer e moje bi malko po speedy da izpolzvash BETWEEN pri float po dobre drugia variant pri stringove epten si niamam na ideia pri datatime ami gledam che neshto mysqla ne se kefi mnogo .....

Kakvi sa vashite nabludenia a ako imate i menenie oshte po dobre :)
a ako pyk i znaete kak mysql-a obrabotva dvata varianta napravo .....

ако производителя е сложил функция и тя работи по зле отколкото ако ти я заместиш със собствена.....уважеми, сами производител бързо ще пусне нова версия, сървиз пак, пач или както там измисли да го кръсти...

моето мнение е, че дори да има частен случай в които написаното от теб решение е по-бързо от готовата функция, това няма да трае дълго....

[линк]

Аз съм ЗА BETWEEN поради чисто естетически съображения

Става по-кратко, по-ясно, по-разбираемо. С две думи по-красиво....

salle.online.bg/sig

Ami zvuchi logichno jalko che ne emnogo ==True popadnah skoro na edin mail ot General Mailing list na mysql-a ta fena beshe napravil dosta podrobno prouchvane po tozi vypros bih go postnal no e naistina dosta goliam i ne e za foruma ...

heh tazi gledna tochka mnogo me radva kefi me prosto na 100%

Моето наблюдение е, че двете алтернативи, които си посочил не са еквивалентни и могат да върнат различни резултати
select * from.... where col>=val1 and col<=val2

Аз по естетически съображения ползвам BETWEEN

Тук вече нещата опират до конкретна реализация т.е. как вътрешно се обработват двата случая

Дали BETWEEN се привежда към два "логически оператора" или е реализирана като функция с 3 параметъра, която връща true, false.

Може да е въпрос на много малки разлики но ако за обработката на (A) AND (B) се извикват вътрешно 3 функции - 1 за изчисляване на A, една за B и една за крайния резултат то загубата от превключването на контекста може да е по-голяма от реализация в стил functoin_between(x, min, max)

И в двата случая има място за оптимизация примерно ако max < min -> false (мисията невъзможна)

Само, че в единия случай отпимизацията може да се направи на ниво код на съответната функция докато в другия случай ТРЯБВА да се направи на ниво анализ на текста на заявката.

Кой случай ще е по-добър ... както винаги зависи.

salle.online.bg/sig

При равни други условия по-разбираемия, по-четивния код е значително по-доброто решение.

И колкото повече хора трябва да четат този код работейки с него толкова по силен е ефекта просто се умножава. Ако ти трябва половин минута по-малко за да разбереш даден ред от нещо пък после го прочетат 200 твои колеги колко време ще спестиш на на екипа? А ако са 20 000? А ако на всеки му се налага да чете по много такива редове на ден?

Тъй, че "красотата" не е самоцелна.

salle.online.bg/sig

излизаш от контекста на въпросса...
мисля, че по доброто решение въпреки всичко е between

освен това, не знам как е на MySql но един нормален компилатор (за С++ си залагам кухата тиква) няма да изчислява В ако А е лъжа(освен ако умишлено не го накараш)...тоест, в някои частни случай трите операции се свеждат до една...

сигурно в хелпа на MySql го пише някъде как точно се изчисляват логически изрази, и сигурно е така както предполагам по горе...въпреки всичко не мисля че замяната с два логически оператора е по доброто решение...

[линк]

Има доста голяма разлика между компилатор и оптимизатор на заявки

Не само защото оптимизатора работи в риално време ами и защото при SQL нещата опират много по-често до въпроса "А така написана заявката може ли или не може да използва индекси.

Не забравяй също така колко е важен редът на изпълнение.
AND позволява изпълнение в произволен ред. И ако компилаторът може и да си няма идея какво ще стане по време на изпълнение то оптимизаторът на SQL би трябвало да може да прецени, кой от двата израза е по-вероятно да "сработи" по-добре и да обработи първо него.

Това е още една огромна разлика. SQL се изпълнява винаги в конкретна среда т.е. при конкретни данни. И ако планът за изпълнение на една заявка днес е един - утре при други дании може да е съвсем друг.


Колкото до това къде в MySQL конкрени е BETWEEN мняма нужда да четеш документация. Затова е Отворения Код

sql/item_cmpfunc.cc:305-445

Всеки коментар на кода е добре дошъл

Проблемът е че всеки си има собствено разбиране кой-код е "четивен" -- обюо взето "моя код е четивен, всеки друг не е".

Аз лично никога не пиша бетвеен щото не мога да запомня включва ли границите или не.

За оптимизацията -- зависи, но съм 90% сигурен че и в двата случая оптимизатора (на сайбейс -- ша го пробвам) прави едно и също нещо. Големия ожерхеад е да прочете данните в паметта, а времето да сметне едно по-голямо е пренебрежимо малко.

не че ще кажа нещо много обосновано, но аз съм привърженик на BETWEEN (може би най-вече заради въпросната четимост)

съгласен съм със забележките...наистина имам само най-обща представа как работи една база данни, тоест - достатъчно за да ми е ясно, че нищо не знам...
но ако подмениш функция със SQL скрипт и скрипта работи по-бързо....това е сериозен повод за размисъл за разработчиците...

[линк]