Цитата:
Сообщение от
mazzy
сложный запрос? из одной? с ветвистой логикой? ))))
да, я тоже обратил внимание на единственное число.
но подумал, что люди хотят не то, что спрашивают, и срашивают не то, что хотят. как обычно. )
В этом случае я сначала задаю уточняющие вопросы. Хотя тут они уже были заданы и без уточнений можно долго разглагольствовать
. Нужен автор с более детальным примером
.
Цитата:
Сообщение от
mazzy
но если предположить твою трактовку:
а какой запрос по какой таблице аксапты ты бы назвал подходящим под определение "сложная и ветвистая логика запроса по одной таблице"?
просто интересно.
InventTrans
В свое время (АХ 4.0) у меня была задача поиска "закольцованных" движений. Соответственно, чтобы понять "кольцо" - нужно для каждой записи (каждого типа движения) применить свой алгоритм обработки. На выходе может получиться неопределенно много записей и тривиальный фильтр не подходит, соответственно ссылку на RecId найденных записей было удобно записывать в RecordReference_RU, а затем открывать стандартную форму InventTrans, отфильтрованную по отобранным движениям.
Цитата:
Сообщение от
mazzy
эмммм. у меня есть соображения по поводу этого класса и по поводу того что надо оторвать автору класса. но давай я попридержу и спрошу:
а что ты имеешь в виду? что должно быть в таком классе? и чем это будет лучше чем набор отдельных запросов в сложной и ветвистой логике?
Набор отдельных запросов в сложной и ветвистой логике однозначно лучше. В классе явно не хватает возможности задавать (а не генерить) parmId. За счет этого получается использование номерных серий. А т.к. функционал в классе скромный (максимум join да flush заслуживает внимания) - то тут как бы особо и добавить нечего.
Цитата:
Сообщение от
mazzy
сложная и ветвистая логика для справочника?
да, ну, брось...
да, я как-то незаметно стал ассоциировать "одну таблицу" со справочником. Каюсь.
Цитата:
Сообщение от
mazzy
я понимаю еще таблицу с проводками. в результате надо получить дебет-кредит с учетом сторно и какие-нибудь хитрые группировки. но группировки по одной таблице проводок, не заглядывая в справочники?
Легко, если:
а) использовать что-то типа InventTrans, из которого еще не выкосили "лишние" поля
б) сознательно денормализовать нормализованные Микрософтом таблицы для ускорения выборок.
Цитата:
Сообщение от
mazzy
а сложную и ветвистую логику для справочника из одной таблицы? дерево что ли? и что там сложного? в общем, не понимаю.
Каюсь, каюсь...
Цитата:
Сообщение от
mazzy
то, что у автора 2009 не значит, что не стоит учитывать и старшие версии.
читают то многие. а вопрос неплохой вроде.
Тогда нужно разделить совет по той версии, по которой спрашивают от совета по более старшим версиям. Вообще, если автор спрашивает про 2009 - то как бы и надо отвечать в первую очередь про 2009. Бонусом можно добавить про другие версии, но в первую очередь ответить надо человеку на тот вопрос, который он задал.
Цитата:
Сообщение от
mazzy
раз все равно придется делать классы, отвечающие за бизнес-сущности,
то может и не заморачиваться с "произвольным запросом"
а сразу сделать нормальные классы? ))))
ну тут не поспоришь - конечно надо делать нормальные классы.