IN фильтр в while select запросе?

[mazzy]

Цитата:

Сообщение от Napalm

Полное непонимание вопроса.

Бггг!!! Napalm, жжоте. Тупо жжоте.

Да, надо разделить вопрос:
= Query vs while select
= in vs range

Query надо использовать ВСЕГДА!
По построению - Query, это программный объект, который позволяет программисту при помощи методов строить и менять запрос. А также (!) использовать переменные условия на переменное число полей. UPD: в том числе добавлять таблицы и условия может и пользователь (!!!!), если ему дали такие права, а программист предоставил соответствующий диалог (как правило, пара методов).

while select - немодифицируемый оператор языка. программист не может изменить запрос, написанный при помощи while select. Делать "переменный" или "модифицируемый" while select - это ссать против ветра.

======================
in - отсутствует в Аксапте
в аксапте присуствует range, сводящийся к OR, AND, NOT

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

===============================

Цитата:

Сообщение от kitty

тк
1) while-select уже существует и переписывать существующую логику в query только для того, чтобы добавить доп условие на 1 поле - имхо, не умно

Бгггг.... Я бы после такого заявления уволил

Цитата:

Сообщение от Napalm

Query плохое решение.

Бггг... туда же

Цитата:

Сообщение от Cardagant

Query и правда не подойдёт, если количество OR может быть очень большим.

А не надо использовать query для большого числа OR (как и для большого числа элементов в IN)
даже до того, как вы упретесь в ограничение длины строки, SQL перестанет оптимизировать план запроса для очень большого числа условий.

странно даже, вроде в реальной жизни никто ножом дрова не колет... а колуном не затачивает карандаши... а с select и Query - полно желающих.

[Napalm]

Цитата:

Сообщение от mazzy

Query надо использовать ВСЕГДА!

LOL.

Цитата:

Сообщение от mazzy

Бгггг.... Я бы после такого заявления уволил

Цитата:

Сообщение от mazzy

Бггг... туда же

Я бы к такому "знатоку" работать не пошел.

[Cardagant]

Цитата:

Сообщение от mazzy

Бггг!!! Napalm, жжоте. Тупо жжоте.
А не надо использовать query для большого числа OR (как и для большого числа элементов в IN)
даже до того, как вы упретесь в ограничение длины строки, SQL перестанет оптимизировать план запроса для очень большого числа условий..

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

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

[Weez]

Цитата:

Сообщение от Cardagant

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

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

Так уже предложили для этого использовать класс RecordReferenceList_RU, который позволяет приджойнть к Query заполненную по любому принципу таблицу, при этом абстрагируясь от низкоуровневых особенностей реализации. Но это работает если джоин можно сделать через RecId записи.

[Cardagant]

Цитата:

Сообщение от Weez

Так уже предложили для этого использовать класс RecordReferenceList_RU, который позволяет приджойнть к Query заполненную по любому принципу таблицу, при этом абстрагируясь от низкоуровневых особенностей реализации. Но это работает если джоин можно сделать через RecId записи.

Да, пусть это будет альтернативным решением.

Здесь акцент был на том, что есть случаи, когда query недостаточен для решения задачи.