Как оптимально написать T-SQL запрос для выборки настройки Table/Group/All (например, счет ГК из профиля разноски)

[mazzy]

Цитата:

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

1. Создаем временную таблицу КодКлиента (группа клиента не нужна), Профиль, СчетГК
...
4. Строим запрос по проводкам с привязкой временной таблицы по INNER JOIN

А заполнять нужно при каждом выполнении запроса?
Или где-то по тригеру? Ведь и клиенты могут меняться, и настройки...

Блин, код жеж нереентерабельный.
Запросы шага 4 нельзя строить пока не будет выполнено построение временной/вспомогательной/зарезолвенной таблицы.

А перестроение придется делать при каждом создании/удалении клиента, плана счетов или настройки.

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

[fed]

Цитата:

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

А заполнять нужно при каждом выполнении запроса?
Или где-то по тригеру? Ведь и клиенты могут меняться, и настройки...

Блин, код жеж нереентерабельный.
Запросы шага 4 нельзя строить пока не будет выполнено построение временной/вспомогательной/зарезолвенной таблицы.


))))

Ну дык добавь колонку с GUID, и засунь ее во все запросы, обновления и индексы. Или ParmId там, если из аксапты обновлять собираешься.
Ах да - и перестраивать при каждом запросе, разумеется. А чтобы не тормозило - построй по custTrans индекс по custAccount+postingProfile.

[mazzy]

Цитата:

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

Ну дык добавь колонку с GUID, и засунь ее во все запросы, обновления и индексы.

оО!
ну нахер http://www.youtube.com/watch?v=HcfHBgUTn7I

[Alexius]

Цитата:

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

А заполнять нужно при каждом выполнении запроса?

Для начала - да, при каждом выполнении. Философского булыжника нет. Нужно пробовать.

SELECT DATAAREAID, COUNT(*)
FROM
(
  SELECT DATAAREAID, ACCOUNTNUM, POSTINGPROFILE
  FROM CUSTTRANS
  GROUP BY DATAAREAID, ACCOUNTNUM, POSTINGPROFILE
) T
GROUP BY DATAAREAID

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

[Vadik]

--

Цитата:

наивный: 4% по плану запроса, выполнено за 1:17, выбрано 342294 записи

Ну, для отчета (если это отчет) - неплохо, примерно столько же времени потребуется чтобы отчет на ее основе тупо пролистать не читая. Ты хочешь что-то дальше оптимизировать? Зачем? У тебя есть отчеты на 15 миллионов строк ? Ты хочешь чтобы они выполнялись за минуту а не за 20 ? Чего-то ты недоговариваешь

[mazzy]

Цитата:

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

--
Ты хочешь что-то дальше оптимизировать? Зачем? У тебя есть отчеты на 15 миллионов строк ? Ты хочешь чтобы они выполнялись за минуту а не за 20 ? Чего-то ты недоговариваешь

Злодей ))) http://coub.com/view/9z36u

я сформулировал свои вопросы в первом сообщении этой темы
Как оптимально написать T-SQL запрос для выборки настройки Table/Group/All (например, счет ГК из профиля разноски)

собственно главный вопрос - Как оптимально написать T-SQL запрос для выборки настройки Table/Group/All (ответ похоже получили. Но так писать не шибко удобно)

побочный квест - как, на ваш взгляд должны быть устроены подобные настроечные таблицы, чтобы и без Аксаптовского кэширования можно было бы удобно работать с такими настроечными таблицами на уровне SQL?

[Vadik]

Цитата:

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

побочный квест - как, на ваш взгляд должны быть устроены подобные настроечные таблицы, чтобы и без Аксаптовского кэширования можно было бы удобно работать с такими настроечными таблицами на уровне SQL?

Удобство - штука относительная. Вот сейчас реализуй то же самое для AX2012, прогони тест со временем выполнения запросов и ты поймешь насколько кучеряво тебе живется на 2009

Цитата:

Злодей

Я знаю

[mazzy]

Цитата:

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

Удобство - штука относительная.

http://coub.com/view/2xtx9

Цитата:

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

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

я в курсе. поэтому и ввел дисклаймер сразу ))))

Цитата:

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

...
И для простоты я предлагаю обсуждать акс2009 и ниже. Поскольку сам принцип выборки данных из настроечных таблиц в акс2012 и выше не изменился. Но общие планы счетов (chart of accounts), безумные финансовые аналитики, включающие счет ГК, только захламят обсуждение, ничего не изменяя в сути вопроса.

===================================
и все таки... может у кого есть что сказать?

Цитата:

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

как, на ваш взгляд должны быть устроены подобные настроечные таблицы Table/Group/All, чтобы и без Аксаптовского кэширования можно было бы удобно работать с такими настроечными таблицами на уровне SQL, Reporting Service, OLAP и прочих внешних систем?

напомню, что сама идеология подобных таблиц появилась еще в Конкорде и в Навижине. Еще на базах собственного формата с построчным обращением к базе. SQL тогда был в младенчестве.

[Vadik]

Не надо лохматить профили разноски. Материализуй связь между проводкой по клиенту и клиентскому счету в ГК через поле в CustTrans или таблицу сбоку и заполняй при разноске. И работать будет "удобно", и проблем с выверкой не будет

[Ярослав Щекин]

Цитата:

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

и все таки... может у кого есть что сказать?

Может быть, стоит пойти с этим вопросом на профильный форум на SQL.RU (хотя там задать его будет посложнее, скорее всего, будут требовать привести скрипты таблиц, статистику, а то и repro, конкретный запрос, и т.д. и т.п.), зато там уж скорее подскажут.

Кроме того, какие-то немного шаманские сравнения получаются.

1. IMHO, стоит включить SET STATISTICS TIME / SET STATISTICS IO (можно в опциях в Management Studio) и хотя бы смотреть, чтобы примерно то же количество чтений были логическими/физическими, и не ждал ли MS SQL во время выполнения кого-то ещё).

2. "То, о чем предупреждал Владимир Максимов" --- посмотреть Estimated number of rows в каждом плане, т.к. если оценки сильно отличаются от реальных, и Вы выберете этот план, то потом можно очень сильно пожалеть... Дело в том, что, выбирая в таких случаях по реальному времени выполнения, Вы просто надеетесь на удачу.

3. Да, а (если не накладывать условий на pSumAccount) сколько занимает такая же выборка из CustTrans? У Вас, похоже, большой её кусок считывается и передаётся на клиента, может всё время вообще на это уходит, откуда нам знать?

4. А какую версию MS SQL Server Вы используете (в разных версиях поведение может кардинально отличаться)?