О ключах - NAV: Программирование

Milk · 06.02.2008, 11:35

Вот уже сколько лет занимаюсь Navision, а впервые задумался о такой ситуации.
Допустим, есть очень большая таблица операций. Надо ее обработать следующим образом: наложить фильтр, содержащий больше одного значения, на какое-то поле, а затем пройтись по таблице в порядке ее первичного ключа. Это что же, сделать быстро в принципе невозможно?

RedFox · 06.02.2008, 11:39

Цитата:

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

Вот уже сколько лет занимаюсь Navision, а впервые задумался о такой ситуации.
Допустим, есть очень большая таблица операций. Надо ее обработать следующим образом: наложить фильтр, содержащий больше одного значения, на какое-то поле, а затем пройтись по таблице в порядке ее первичного ключа. Это что же, сделать быстро в принципе невозможно?

Ну мне кажется, что под Нав-движек наверное да (иначе нужно будет вызывать REMANE, который потянет столько "изменений"...).

Milk · 06.02.2008, 12:50

Да, теперь мне стало глубже понятно, зачем Аналитические отчеты запоминают номер последней операции

rov_imported · 08.02.2008, 13:10

Цитата:

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

Допустим, есть очень большая таблица операций.

Скажем, Товар Книга Операций?

Цитата:

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

наложить фильтр, содержащий больше одного значения, на какое-то поле

Например фильтр на поле Документ Но? Фильтр естественно по нескольким значениям?

Цитата:

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

а затем пройтись по таблице в порядке ее первичного ключа.

Вот тут не очень понял. Что значит "пройтись в порядке первичного ключа"?
То есть перемещаться между отфильтрованными записямии при этом они отсортированы по порядку первичного ключа? А ключ вы выбираете или нет? То есть фильтр по полю наложили - это поле в составе ключа или нет?
Если - нет, то понятно, что будет медленно - так это и везде так будет-в любой базе.
А если поле есть в ключе- так и работать будет быстро.
Или я что-то недопонял?

Milk · 08.02.2008, 14:50

Цитата:

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

Скажем, Товар Книга Операций?

Например. Или Фин. Книга, или Стоимость Операции - в общем, где со временем количество записей начинает измеряться миллионами.

Цитата:

Например фильтр на поле Документ Но? Фильтр естественно по нескольким значениям?

Да, важно, что именно по нескольким

Цитата:

Вот тут не очень понял. Что значит "пройтись в порядке первичного ключа"?
То есть перемещаться между отфильтрованными записямии при этом они отсортированы по порядку первичного ключа? А ключ вы выбираете или нет? То есть фильтр по полю наложили - это поле в составе ключа или нет?
Если - нет, то понятно, что будет медленно - так это и везде так будет-в любой базе.
А если поле есть в ключе- так и работать будет быстро.
Или я что-то недопонял?

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

grif · 08.02.2008, 16:33

Не проще ли скопировать нужные записи во временную таблицу, отфильтровав с нужным ключом, а уже во временной сортировать по первичному?

RedFox · 08.02.2008, 16:44

Цитата:

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

Пока писал, придумал изврат: добавить новое поле в таблицу и вначале ключа поставить новое поле, которое никогда не будет заполняться, а потом уже "Entry No."... Гы, а ведь хоть какое-то решение

Так поставте фильтруемое поле вперед.

Fordewind · 08.02.2008, 16:49

Цитата:

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

Не проще ли скопировать нужные записи во временную таблицу, отфильтровав с нужным ключом, а уже во временной сортировать по первичному?

Тоже подумал об этом. Но тогда есть вопрос еще в скорости копирования большого числа записей

(Временные таблицы хранятся на клиентской машине)

rov_imported · 08.02.2008, 16:51

Цитата:

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

Так поставте фильтруемое поле вперед.

А тогда записи будут отсортированы по этому полю, а не по первичному ключу!

Не катит...

Milk - а решение с фиктивным полем на самом деле классное! Действительно решит проблему.
Про то, что нельзя сделать вторичный, начинающийся с первичного - блин как-то не сталкивался ни разу,
и не знал про это. Или знал - но забыл...

Fordewind · 08.02.2008, 16:52

Цитата:

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

Так поставте фильтруемое поле вперед.

Это тоже самое, что просто сделать вторичный ключ только по фильтруемому полю. И это не подходит

Milk · 08.02.2008, 16:57

Цитата:

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

Не проще ли скопировать нужные записи во временную таблицу, отфильтровав с нужным ключом, а уже во временной сортировать по первичному?

Согласен, в некоторых случаях это сработает - если записей отфильтруется немного, допустим, надо отобрать записи по нескольким документам. Но иногда само копирование будет идти очень долго. Я неспроста написал про Аналитические Отчеты - там этот недостаток системы особенно явен. Записи Фин. Книги операций: 1.Фильтруются по некоторму множеству счетов; 2.Фильтруются по значениям некоторых измерений - тут цикл; 3. Начинается поиск в порядке возрастания номера операций внутри цикла. Очень неэффективно.

grif · 08.02.2008, 16:58

Цитата:

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

Тоже подумал об этом. Но тогда есть вопрос еще в скорости копирования большого числа записей

(Временные таблицы хранятся на клиентской машине)

Ну по правильному ключу должно быстрее, чем перебирать эти же записи с первичным

RedFox · 08.02.2008, 17:06

Цитата:

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

А тогда записи будут отсортированы по этому полю, а не по первичному ключу!

Не катит...

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

satir · 08.02.2008, 21:05

Цитата:

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

Вот уже сколько лет занимаюсь Navision, а впервые задумался о такой ситуации.
Допустим, есть очень большая таблица операций. Надо ее обработать следующим образом: наложить фильтр, содержащий больше одного значения, на какое-то поле, а затем пройтись по таблице в порядке ее первичного ключа. Это что же, сделать быстро в принципе невозможно?

Проверить нет возможности. Вдруг сработает.

Код:

setcurrentkey(ключ для фильтра)
setfilter
find('-')
setcurrentkey(первичный ключ)
find('-')
repeat
until

rov_imported · 11.02.2008, 09:04

Цитата:

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

Мне не понятно цель операции в таком случае.

ну вообще это конечно вопрос к автору - для чего ему это надо.
Но я бы с ходу придумал бы такой пример:
необходимость отследить хронологию ФИФО. Для этого необходимо отфильтровать ТКО по типу "Продажа"
(этого в задаче нет - но суть не меняется), затем налоджить фильтр по дате, например с 01.02.08 по 05.02.08.
Причем записи должны быть отсортированы по первичному ключу. В результате, если не было нарушений
хронологии учета - то все даты в операциях будут возрастать. Более свежая операция - большая дата. А если
хронология нарушена - то более свежие даты будут в начале списка, ну или раньше, чем менее свежие даты.

RedFox · 11.02.2008, 10:58

Цитата:

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

ну вообще это конечно вопрос к автору - для чего ему это надо.
Но я бы с ходу придумал бы такой пример:
необходимость отследить хронологию ФИФО. Для этого необходимо отфильтровать ТКО по типу "Продажа"
(этого в задаче нет - но суть не меняется), затем налоджить фильтр по дате, например с 01.02.08 по 05.02.08.

Вторичный ключ работает нормально

Цитата:

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

Во-первых не забываем, что в NAV в конце каждого вторичного ключа добавляется первичный (типа для уникальности, но более правильно описано в доке по SQL). Поэтому обычно они и будут либо возрастать (ASC), либо убывать (DESC)
Во-вторых, корректные нарушения так не выявишь

Milk · 11.02.2008, 11:56

satir, нет, так систему обмануть не удастся

Цитата:

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

ну вообще это конечно вопрос к автору - для чего ему это надо.

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

RedFox, мне кажется, вы что-то упускаете в обсуждении

RedFox · 11.02.2008, 16:10

Цитата:

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

RedFox, мне кажется, вы что-то упускаете в обсуждении

Наверное, я не спорю. Но как писал ранее, на SQL-версии это можно было бы сделать путем изменения самого SQL-запроса, который будет генерироваться с участием ORDER BY.
А для "аналитики" я бы вообще использовал бы SnapShot или реплицированную базу, вынесенную на отдельный сервер.

romeo · 11.02.2008, 16:20

А почему не будет работать варинант, предложенный Сатиром??
<div class='CALtop'>C/AL</div><div class='CAL'>SETCURRENTKEY("Posting Date");
SETRANGE("Posting Date", DateFrom, DateTo);
IF NOT ISEMPTY() THEN BEGIN
SETCURRENTKEY("Entry No.");
IF FIND('-') THEN REPEAT
...
UNTIL NEXT = 0;
END;</div>

Или работать будет, но также медленно?.

Milk · 11.02.2008, 17:48

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

romeo, да, системе же все равно, что когда-то стоял другой ключ. Она видит текущий фильтр и ключ. И тормозит.