Мысль средыВопрос: Нет-ли у великого All каких-либо наработок, мыслей по вопросу создания фильтра с прицелом на универсальность решения.
Фильтр имхо должен быть универсальным компонентом, в котором легко и удобно описываются "правила, заточенные на конкретный случай".

Универсальный фильтр, который будет самостоятельно рыскать по словарю - занятие весьма бессмысленное. Для универсальных же продуктов ничего лучше и не сделаешь, а для прикладной системы это плохо. Просто как пример - бизнес-правило "дешевые клиенты - клиенты, купившие товара менее чем на X рублей" в терминах словаря описывать неудобно, а фильтр по таковым пользователи запросто могут захотеть. Опять же, "универсального фильтра", который позволит найди счет по условию на его позицию (скажем, "в счете есть товар такой-то") как правило не наблюдается, все сплошь тупейший QBE.

Роман ДынникНа мой взгляд, давать возможность использовать подобные фильтры стоит только на клиенте. Т.е. подобный фильтр не должен быть серверным
:((

Роман ДынникА по клиентским коллекциям пусть ищут сколько душе угодно и как захотят.
То есть для начала надо закачать на клиента 10.000.000 записей, чтобы потом искать в них "сколько и как душе угодно"? Сомнительный подход, имхо.

Роман ДынникА то что каждый серверный фильтр у вас заточен под конкретный справочник/журнал - это правильное решение, особенно с точки зрения безопасности и "защиты от дурака".
Хм. Особенно любопытно насчет безопасности. Это что, так хреново сделана безопасность, что любой фильтр ее запросто пробивает?

Роман ДынникДа нет, получил коллекцию по "жесткому фильтру", например журнал по диапазону дат,
И сколько в этой коллекции записей? Just for example - новые контракты МТС за последний год.

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

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

Роман Дынник softwarerХм. Особенно любопытно насчет безопасности. Это что, так хреново сделана безопасность, что любой фильтр ее запросто пробивает?
Хреново - если вы даете возможность пользователям собственоручно джоинить таблицы и вьюхи, да даже если вы вообще даете к ним доступ, а не используете для выборок и прочих операций с БД слой хп.
Господи, опять эта сказка :( От Вас, признаться, не ожидал этого примитива.

Итак:

1. Будьте добры, приведите пример нормально сделанной системы безопасности, которую пробивает некоторый "произвольный фильтр с клиента". Посмотрим, действительно ли она нормально сделана.

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

2. При чем тут ХП? Я могу сделать все через ХП, если Вам так сильно хочется, и это не помешает произвольным запросам. Этот класс решений, конечно, на любителей экстрима, на тех, кто "потому что ХП - руль", но если хочется - кто мешает?

3. Если Вы действительно уверены в том, что сказали, расскажите, пожалуйста, что ХП даст безопасности такого особого, что никак иначе не сделаешь. Сразу скажу: страниц будет много, но рассказать не сможете. Разве что про отдельные недоработки отдельных СУБД.

Alexey KudinovДавайте разрешать пользователю затянуть все 15 000 000 строк в грид
Зачем? Зачем обосновывать одно кривое и неправильное решение другим кривым и неправильным решением?

Alexey Kudinovкстати тему производительности запросов отданых на откуп пользователю пока никто не затронул.
Думаю, отчасти ее затронул Роман, говоря про "защиту от дурака".

Согласен, это проблема. Мое личное мнение: как пользователь, я однозначно предпочту вариант "нужный функционал есть, но медленный" варианту "нужного функционала нет, приходится извращаться, например применять ближайший похожий стандартный фильтр, выписывать нужное на бумажку, выбирать другой похожий фильтр, дописывать на бумажку...."

Разумеется, пользователь может формулировать задания на доработку (если может). В одном случае - на новый фильтр, в другом случае - на ускорение выборки по часто используемому условию.

Alexey Kudinovглавная беда этих "произвольных фильтров" в том, что далеко-далеко не факт, что они будут востребованы _пользователями_
Тут как всегда правило 10/90. Иначе говоря, 10% пользователей любой программы без этой функциональности будут страдать.

Скажу так: по моему опыту, пользователи порой вводят такие сложные фильтры, которых я сам не никогда не использовал. Я видел сохраненные фильтры на 40-50 "элементарных условий" (элементарное условие - это =, like, in итп.)

Alexey KudinovЧто тетя Маша из бухгалетерии сама будет заниматься "этой ерундой", а не звать _программиста_ Васю.
Звать программиста она будет, если нужного ей жесткого фильтра нет. При настраиваемых фильтрах она скорее попросит соседку, молодую и умную Машеньку, настроить и сохранить такой же фильтр и ей тоже.

Роман Дынникэто не даст пользователю наджоинить дюжину таблиц и вьюх самих на себя
То есть первичная задача программиста - не дать пользователю сделать то, что ему нужно? Любопытная постановка вопроса. Я даже знаю, как очень легко написать программу, в высшей степени отвечающую этому критерию. Не знаю, правда, как продать ее без использования откровенно нечистоплотных методов.

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

Роман ДынникЗапусте профайлер для базы 1С :)
И? Не знаю 1C, но совершенно уверен в том, что легко отыщу кучу куда худших приложений, фильтры в которых построены точно в соответствии с Вашими рекомендациями. И что из этого?

Роман ДынникЗачем же так категорично?
Потому что это так. Строго математически.

Роман Дынник-параметры по-умолчанию
То есть тот же самый фильтр. Нарушение первого критерия.

Роман Дынник-ограничте выборку top-ом
То есть тот же самый фильтр. Нарушение первого критерия.

Роман Дынники генерите сообщение "слишком много записей, уточните параметры запроса".
Как же я их ограничу, если фильтр жесткий? Только за счет нарушения первого критерия.

Роман Дынник-постраничная выборка
Вот это правильно, только не в том месте. Это ответ Алексею про затаскивание пятнадцати миллионов строк в грид и как следствие обоснование ненужности заранее прописанных жестких фильтров.

Здесь же это решение не проходит из-за клиентского фильтра. Чтобы отфильтровать выборку на клиенте, мне необходимо ее туда затянуть, затянуть целиком. Скажем, фильтр: "все счета за последний год, в которых присутствует позиция "телефон Siemens A65". Расскажите, пожалуйста, как обойтись частичной выборкой, если предположить, что за последний год таких счетов всего 15 из 100'000, серверный фильтр есть только по условию "за последний год".

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

Допустим, моя текущая работа - бюро кредитных историй. И вот представьте себе, звонит мне пользователь и говорит: моя специальность - однодневные кредиты, я бы хотел видеть только их. Оцените, пожалуйста, следующие варианты моего ответа по степени вменяемости:

Да нет проблем. Введите вот такой фильтр и сохраните его как фильтр по умолчанию

Да нет проблем. За $1000 мы сделаем соответствующую доработку

Да нет проблем, Вы только учтите, что это уже аналитическая отчетность. За $100'000 мы разработаем для вас хранилище данных, и Вы сможете запрашивать в нем список однодневных кредитов, правда не сегодняшних - закачка у нас раз в сутки. Далее переписываете их номера на бумажку, идете в нашу первую программу и там по одному ищете их с помощью кнопки "поиск в выборке из NNNNN записей".

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

Роман ДынникМое мнение такое: настраиваемые пользователем серверные фильтры - для коробочных решений. Действительно нельзя предугадать все желания пользователей.
А чем более эксклюзивные программные продукты хуже? Их пользователи рыжие? Или наша цель - загнать всех в светлое будущее 1C?

Роман ДынникДля постоянно поддерживаемых систем, внутренних, 24x7, OLTP с высокой нагрузкой - это чреватое нехорошими последствиями решение.
Для нормально настроенного сервера это решение "чревато нехорошими последствиями" разве что для пользователя, выполняющего такой запрос, если он медленный. Все прочие спокойно работают.

Также напомню, что "отсутствие необходимого функционала" - уж точно чреватое нехорошими последствиями решение, абсолютно вне зависимости от 24x7, OLTP и всего прочего.

Роман Дынник softwarer1. Будьте добры, приведите пример нормально сделанной системы безопасности, которую пробивает некоторый "произвольный фильтр с клиента". Посмотрим, действительно ли она нормально сделана.

Устойчивость к DOS-атакам уже не рассматривается как критерий безопасности?
Мне это казалось очевидным, но согласен, формулировку ради корректности стоит уточнить. Итак, уточненный вопрос:

1. Будьте добры, приведите пример нормально сделанной системы безопасности, которую пробивает некоторый "произвольный фильтр с клиента" и не пробивает "жесткий фильтр". Посмотрим, действительно ли она нормально сделана.

Роман Дынник softwarer
Видимо, не стоит и упоминать о том, что хорошо сделанная система безопасности должна выдерживать подключение пользователя не штатным приложением, но "левой" программой типа sqlplus

Должна, поэтому, и отбираем все права на таблицы и вью и даем ролям permitions только на exec sp.
"Поэтому" - ложное следствие, отношения к безопасности не имеющее.

Роман Дынники это не сказка :)
Cказка. И смайлик не делает Ваше утверждение убедительнее.