О ключах

[Milk]

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

[RedFox]

Zitat:

Zitat von Milk

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

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

[Milk]

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

[rov_imported]

Zitat:

Zitat von Milk

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

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

Zitat:

Zitat von Milk

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

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

Zitat:

Zitat von Milk

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

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

[Milk]

Zitat:

Zitat von rov

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

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

Zitat:

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

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

Zitat:

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

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

[grif]

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

[RedFox]

Zitat:

Zitat von Milk

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

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

[Fordewind]

Zitat:

Zitat von grif

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

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

[rov_imported]

Zitat:

Zitat von RedFox

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

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

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

[Fordewind]

Zitat:

Zitat von RedFox

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

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

[Milk]

Zitat:

Zitat von grif

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

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

[grif]

Zitat:

Zitat von Fordewind

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

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

[RedFox]

Zitat:

Zitat von rov

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

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

[satir]

Zitat:

Zitat von Milk

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

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

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

[rov_imported]

Zitat:

Zitat von RedFox

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

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

[RedFox]

Zitat:

Zitat von rov

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

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

Zitat:

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

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

[Milk]

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

Zitat:

Zitat von rov

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

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

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

[RedFox]

Zitat:

Zitat von Milk

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

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

[romeo]

А почему не будет работать варинант, предложенный Сатиром??
<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]

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

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