Задача следующая: знаю уровень, знаю формат ключа. Нужно сделать такое:

SELECT FILTER([Dimension].[Level].Members, [Dimension].CurrentMember.Key > значение) ...

К сожалению функции Key нет.

Как добиться желаемого результата?

MoshaЕсли для AS2005...
И для AS2000, и AS2005. Обьясню что делаю: нужно сделать select from DATE1 to DATE2. Проблема много раз поднималась в этом форуме, но без ответа.

Если нам нужно сделать выборку от дата1 до дата2, то запрос


может и отвалиться, ибо нет гарантии что мембер [2005].[12].[1] существует.

Поэтому я сделал так: time dimension с уровнями Year, Month, Date. В уровня Date ключ построен по принципу YYYYMMDD, то есть 20060320 например. Теперь чтобы сделать выборку от дата1 до дата2 (введенных пользователем вручную в обычных edit-box) мне надо найти первый мембер у которого ключ >= дата1, и второй у которого ключ <= дата2. То есть, выборку делаю так:


Все работает, но очень сомневаюсь что этот MDX эффективен, поэтому и прошу помощи - может ли кто-нибудь подсказать как этот запрос оптимизировать? В частности, не нравится мне HEAD(Filter( - нужно что-то типа "SELECT TOP 1 ... WHERE Key >= значение". Как можно сделать по другому?


P.S. Большая просьба: не надо мне здесь советовать сделать интерфейс таким, чтобы пользователь не мог ввести несуществующую в иерархии дату. Я этот подход предложил своему клиенту (контрол = выпадающее дерево) - он отказался, и полностью обоснованно: его пользователи привыкли вводить вручную две даты в едит-боксах, нажимать кнопочну "Генерировать отчет", и получать в отчете данные за введенный промежуток времени.

Dmitry BiryukovСделайте для измерения времени отдельную табличку со всеми датами. Это решит и эту проблему и избавит от других в будущем.
Мы уже думали так сделать. Но никто юзерю не запретит ввести 01.01.2050 - 01.01.2060. В больших организациях (сам в подобной работал) всегда найдутся те, кто введет ровно такие данные, на которых апликация даст сбой, причем сделают это они неумышленно.

Потом, такой подход с [TimeYMD].[2005].[12].[1] не позволит ничего сделать с измерением, например добавить в него уровень Quarter. То есть, он накладывает ограничение что time-измерение должно быть [Y].[M].[D], и с этим ограничением клиент не согласен.

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

Dmitry Biryukov опять же структуру измерения можно прочитать из мета-данных

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

К сожалению, нет нормальных возможностей работы с time-измерениями. "Time" - это всего-лишь маркер, который приписан к измерению, ровно так как и тип уровня "Year", "Month" - это маркеры, которые потом используются для того чтобы функции YTD работали. Нехватает функций типа
PeriodsFromTo(две даты) которая бы возвращала set и действительно сравнивала бы member-ов с реальными датами, так чтобы это работало независимо от того, как построен time dimension.

То есть, операторы "member < date", "member > date" "member = date" к не реализованы. Была бы супер-фича в AS 2007... а пока надо делать это самому.

Dmitry Biryukovмне кажется, что Вы себя жалеете и не думаете о заказчике.
Потрудитесь написать дюжину строчек кода для создания действительно качественного приложения.
Дмитрий, ну зачем так судить? Вы же не знаете всех деталей...

Приведу пример. У них используется своя нумерация дней, месяцев, недель. То есть, дата 2004-12-31 по ихнему может равнятся 2005-01-31. То есть, три дня из последнего месяца (29, 30, 31 декабря) считаются у них первыми днями первого месяца 2005-го фискального года. Ну и как Вы с этим будете делать подход [Y].[M].[D]:[Y].[M].[D]? M в измерении не совпадает с реальным месяцем... Я Вам могу еще пару примеров привести, но нету времени. Поверьте, способ генерации запросов [Y].[M].[D]:[Y].[M].[D] в зависимости от структуры измерения не пройдет, мы уже не один день потратили на этот вопрос.

Было бы разумно сделать два дроп-дауна с выпадающим деревом, чтобы пользователь смог себе выбрать период. И все проблемы отпадают. Вот только "привычка свыше нам дана - замена счастию она" - если бы клиент до этого ничего не юзал, у него бы привычки вводить руками две даты не было бы, и этот подход ему бы полностью подошел.

Так что лучше помогите оптимизировать запрос (если знаете как).

Уже вижу способ без HEAD/TAIL:


Есть еще оптимальнее?

backfireПри желании можно написать алгоритм заменяющий сет из большого чрсла мелких элементов, еквивалентным, состоящим из меньшего количества родительских элементов.
Именно это и буду делать. Только это уже вторая задача. А первая задача - это найти оптимальным способом того мембера, у которого key >= значение. Как это сделать с помощью HEAD+Filter - я уже показал. Другой способ знает кто нибудь?

P.S. на многих <skip by moderator> форумах вижу одну и ту же проблему: народ любит отвечать не на тот вопрос, что задан, и тем самым мешают автору топика получить тот ответ, который ему нужен; а вместо ответов идут "оценки" деятельности автора топика.

Народ, мне не нужны Ваши оценки нас как разработчиков. Нас КЛИЕНТ будет оценивать, и делать он это будет не по обрывкам информации (как здесь), а по реальным результатам. В этом топике я поднял техническую проблему - "как найти близлежайшего мембера". Если знаете способ как сделать лучше чем HEAD+FILTER и Вам не жаль им поделится - буду очень благодарен.

Ну и что это за "<skip by moderator>"?

кто-то пробует заблокировать кусок сообщения? а что, правда в глаза колет?

кажется понял. прошу прощения если неправильно выразился. я имел в виду "русскоговорящих" форумах.

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

Еще под вопросом, что лучше: "ты спросил, я ответил, ты сказал спасибо", или же "ты спросил, тебя осудили, отвели тему в сторону, и пр."

Dmitry Biryukovздесь общаются люди более высокого уровня, чем программисты. Они умеют ставить и решать проблемы, а не просто выполнять задачи.
относительно контингента этого форума на 100% согласен. но разве это дает им право судить? это касается не только моего топика - я много топиков прочел, и чаще всего здесь вижу как кто-то действительно хороший спец (не буду называть по именах кто именно, ибо здесь, как я понял цензура - всеравно модератор сделает "skip by moderator") вместо того, чтобы посоветовать человеку как решить его проблему, начинает осуждать его действия.

Такого подхода я не видел на англоговорящих форумах. Я когда-то давно видел еще в ФИДО такое - там вообще нельзя ничего спросить - с вероятностью 99% тебя осудят (вместо того, чтобы помочь).

Dmitry Biryukovпо делу: всё равно не пойму, почему по двум введённым датам нельзя сгенерировать имена двух существующих членов измерения?

Пример почему нельзя. У клиента в частности есть внутненняя схема дат, по которой "29.12.2004real" = "29.01.2005fiscal". Если пользователь введет реальную дату 29.12.2004, то как мне из нее получить [2005].[01].[29]?


Dmitry BiryukovВ самом крайнем случае в таблице дат для каждой даты укажите имя члена измерения даты. работы на час, а сколько времени сэкономится на выполнение запросов!

Вот это хорошая идея. Спасибо. Есть только один недостаток: привязка к транзакционной базе (в которой будет таблица дат). То есть, администратор на стороне заказчика при желании поменять дименшн должен будет обновить таблицу дат. Но этот недостаток несущественный по сравнению с тем, какой impact на перфоманс будет давать HEAD+FILTER.

backfireIMHO, извраты в виде ОТ листа : ДО листа на 99% результат плохого анализа требований и дизайна.
Привыкли они, и ничего тут не поделаешь. Они уже очень долгое время пользуются системой отчетности на транзакционной базе, в которой для каждого отчета нужно руками ввести ДАТУ-ОТ и ДАТУ-ДО. Попробуй-ка простым сметртным выкинуть message box типа "такой даты не существует в базе" - и они задолбут тебя дзвонками так, что лучше бы уже подождали пока MDX найдет первую подходящую дату после ДАТЫ-ОТ и первую перед ДАТОЙ-ДО.

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

MoshaУчитывая что измерение времени небольшое, нет большого смысла оптимизировать построение сета от и до. Решение Игоря с фильтром будет работать хорошо. Правда оно основывается на лексиграфическом сравнении строк, но если формат ключа ГодМесяцДень, то должно сработать, хотя я бы наверное все таки преобразовал бы тип.
Моша, позвольте спросить, планируете ли Вы в следующей версии MSAS добавить функции для манипуляции с членами time-измерения, которые бы "понимали" что такое дата, и не были привязаны к структуре измерения? Я имею в виду, например, функцию которая возвращает сет из мемберов, отвечающих дате, которая >= за заданную?