Abel... правда тогда нужен update и теряется вся прелесть метода :(

Итак, подведем итог: выявилось 2 перспективных подхода, которые надо будет обкатать на практике.
1) от Alexey_Sh
2) от 4321.
Всем спасибо. Если будут еще идеи, пишите :)

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

Метод хорош тем, что всегда (в запись) вовлечены только элементы, меняющие своих впредиидущих. (можно вести и как историю - нет проблем). "Плох" тем, что очередь строится рекурсивно (а не наперед ограниченным количеством SQL запросов). Но, если учесть, что в ваших руках VBA -нет проблем скрестить этот экономичный к данным (и к их изменению) способ хранения списка с SQL - просто пишете свою функцию-указатель на предка(потомка) и (ее же, но с другим параметром) - ф-ию расчета порядкового номера, пара индексов сделает это еще и быстрым. +Чтобы инициировать набор данных для ф-ии 1 раз - вызов с третьим параметром инициирует/очищает статик переменную. После этого все выборки строятся легко и непринужденно в SQL.

еще способ - почитать как устроены индексы (структуры их размещения), и попытаться реализовать их аналог.

AbelЗЫ
2 4321
Фуннция расчета цепочки это либо цикл в лоб по указателям, либо рекурсивная функция? Это значит при сортировке для расчета каждой позиции гонять цикл по всей таблице...


Вариантов больше 2х. Например однократное заполнение расчетного статик массива или коллекции (в зависимости от доминирующего типа предполагаемых вызовов) (если объем данных не шибко велик) при первом вызове (если массив пуст - его заполняем, нет - возвращаем значение) и возврат уже посчитанных значений при каждом последующем. В этом случае цикл "гоняется" для первой (попавшейся) позиции, и не гоняется для всех последующих. Только во все запросы надо не забывать вписывать в WHERE стартовый вызов ф-ии, переопределяющий статик переменные (в т.ч. обнуляющий массив/коллекцию - а то вдруг данные поменялись между 2-мя запросами). Для заведомо небольшой очереди допустимо, но нужно ли? Кстати, вероятно возможен выигрыш по скорости за счет снижение затрат на чтение из больших таблиц с "полными" очередями. Если нормально заоптимизировать вызовы/расчеты. И если результаты расчетов влезут в оперативку, а не полезут в своп.

Abel2 4321
А историю всей очереди хранть не получится: указатели ведь должны быть однозначными. С другой стороны, а так ли она необходима?...

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

Abel
То что вызывать функцию в каждом запросе это понятно. Но ведь пока даже один цикл считается, ДРУГОЙ пользователь изменяет очередь и у клиента может получится 2 разных номера.

В вызове из запроса у вас заполняется статик массив - никакие изменения в исходном наборе на него уже не подействуют. В самом процессе расчета массива тоже можно либо брать снапшот (но тогда не доступны, кажется, индексы - придется ходить Find-ом, а не Seek -ом, что медленно), либо объявлять транзакцию (надо смотреть, не скажу влет что будет в транзакции с рекордсетом, который dbOpenTable при сторонних изменениях).
Abel
есть идея хранить таблицу в виде:
(id_клиента, код_сортировки, подкод_по_порядку, дата_вставки, дата_отмены)
Любое изменение: INSERT новой записи и UPDATE одной отмененной. Можно делать выборки по дате и блокируется при изменении всего 2 записи. Расчет номера по Count(*) WHERE [код] + [подкод] <= (N + M)
Правда это только если вставка будет всегда в конец группы по коду. Надо уточнить.

не въехал

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

Мшсещырф авторВот только пересчет указателей при вставке в середину затрагивает почти полдерева

только пересчет номеров .(!)
(поэтому его иногда ведут динамически)
к-во затрагиваемых указателей (записей) при вставке всегда не больше 3х.
(предыдущая, следующая и вставленная)

A<-B<-C
A<-D<-B<-C
При перестановке добавляется еще 2. Итого максимум 5
см в тексте:
[quot]...как "указатели" (некие расчетные величины на обходе дерева) на правый и левый элементы по обходу[\quot]
- вах, ми в этам смисле "указателей" - именно как номеров по обходу - они меняются для всего дерева далее по обходу от места вставки.

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


ЗЫ кстати обход очереди, в силу отсутствия ветвей, вырождается просто в её нумерацию. (т.ч. будет не отличимо от хранения снимков очередей).

Abel 2 Мщсещырф
В том то и прикол, что стоящий в очереди НЕ должен знать кто перед ним и за ним. Только номер. Да ладно с ним, а вот МЕНЕДЖЕР должен создавать "список очереди" (финансовый документ!!!) и иметь возможность вставлять в середину.
не принципиально для организации данных (в смысле реализуется интерфейсом, а не схемой данных)
Abel
Вообщем см. постановку задачи в первых постах.
кроме того, что это должен ыбть перестраиваемый список я ничего содержательного в постановке не видел. (иметь возможность видеть историю, разве что - как опция)
Abel
2 4321
а) Ну вот, благополучно вернулись к предыдущему варианту :)

http://www.sql.ru/search/search.asp?wci=rcdoc&url=http%3A%2F%2Fwww%2Esql%2Eru%2Farticles%2Fmssql%2F01091502TreesInSQL%2Eshtml&ex=1&pool_size=10&is=exsqlru&context=Joe+Celko&contextcond=phrase&body=1&orderby=%24rel&doc_per_page=10&output=full - можно, кажется, рассматривать как перенос идеи сквозной нумерации со списков на деревья (в силу неопределенной наперед топологии дерева требуется 2 номера "правый" и "левый" для ее восстановления по "нумерации")
Abel
б) Я имел ввиду что уникальность без даты и истории, если update'ть указатели. Колец не будет. Если же только insert'ить, то тогда конечно Вы правы.
Почему не будет колец? (Пристроим 5 за 10 (проапдейтим его ссылку, + пусть 11-го для простоты еще нет), а ссылку 6-го оставим на месте - схема данных позволит -> "снятие" проблемы только через запрещение несогласованных изменений (триггер в серверном случае, запрет обхода некой процедуры перемещения узлов - в случае клиентсого контроля)
Abel
в) Почему же "не въехал"??? Я имел ввиду не дерево, а новые условия задачи (см. пост от 14.12.04 21:17). В распоряжение попал почти естественный ключ (код даты), и только при одинаковой дате (бывает у 2-4 записей) прибавлять "доп. ключ". Сортировка становится элементарной. Но есть пока неясности в ТЗ по этому вопросу.
пост от 14.12.04 21:17 не читабелен (не понятоблян).

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

Только вот (сплошная) нумерация у вас "по любому" рекурсивна - в отличии от хранения номеров "битой цифрой" вы не гарантируете сплошности и постоянства приращения "меры" вдоль очереди. Провести сопоставление с натуральным рядом множества с такой "мерой" можно только по результатам проведения процедуры "натурального" упорядочивания (ORDER By [мера]->recorset->absolutposition->Number), что автоматом правда делается (только) в отчетах.

Abel 2 4321
Типа не понял: зачем это
4321 (ORDER By [мера]->recorset->absolutposition->Number)
В отчете достаточно ORDER BY + нумерация с накоплением по +1, а для получения отдельного номера почему не подойдет count(*) WHERE date <= datQueue ?
это просто прорисовка внутреннего механизма получения номера, что оно само делается в отчетах я сказал. ИСпользование для нумерации вложенного запроса с count(*) WHERE date <= datQueue внутри некой большой выборки просто на порядок медленнее однократной загрузки рекордсета с возвратом из него всего необходимого обычным seek.

Abel 4321Почему не будет колец?
11 как раз должен быть. Он будет называться EOF, а самый первый BOF. Вставка только между ними. Две сцилки на элемент "5" нарушат уникальность. И поле сцилок должно быть not null.

ну вот вы и тор... начинаете изобретать механизм.

Если not null + уникум -на чито ссылаются ваши искусственные EOF и BOF? (2 ссылки возникают, если только не закольцевать BOF на EOF - вы так и собирались?). Но тогда как удалить из кольца (с сылочной целостностью, надо полагать) хоть что-то? перед удалением придется перецепить ссылку у потомка (из за целостности) -> возникнут осложнение с уникальностью ссылок, а в NULL вы ее установить запретили. При этом если есть элементы за пределами EOF и BOF ("служебные") - они обязаны быть замкнуты в кольцо (в простейшем случае - сами на себя) - по тем же причинам уникальной не нулевой ссылки. Если попытаетсь пожертвовать ссылочной целостностью (вторичным ключем по pid) то это и того хуже - кто проверит целостноть в очереди? (т.е. наличие ссылаемого у ссылающегося)

(можно правда так: .Requerd = False, и на _уровне таблицы_ правило типа NOT (pid IS NULL AND (id <> [eof] or id <> [bof]....) (вставлять в свойство таблицы, а не поля) где [eof] и [bof] (...) - константы, равные значениям id в BOF и EOF (и иных служебных). В итоге должно таки получится и средствами аксессовских правил. и без искуственного кольца. Если ввести [fof] - служебный элемент тоже с Null ссылкой в pid за пределами ([bof],[eof]), то ссылки следующего за удаляемым можно будет временно переключать по 1-й перед удалением.......

но нужен ли вам весь этот гемор? (или вы надеетесь, что внутри транзакции проверки целостности не производятся?

авторА разве нельзя его временно сослать самого на себя?
а как же следующий (и уникальность?) То же и с самоссылкой БОФ (1-й последователь запрещает самоссылку - из за уникума)

AbelСогласен. А идея с самоссылкой боф появилаь еще до not null :) Кстати, контроль ссылочной целостности вроде можно отключить? При not null и уникальности возниклновение "висячей" ссылки маловероятно.
???

мдя-с...


ладно, не поленюсь:
вставляем А, наследуем от него Б, удаляем А. - "маловероято"???? .

При "списках" не отвертитесь от проверки отсутствия паразитных колец. Что легко понять:

1. уникум - обеспечивает только отсутствие ветвлений.
2. (целостность + нот нулл) - и только напару - обеспечивает отсутствие разрывов (данные организованы в множество колец, самое малое - из 1 элемента - самоссылка). Но не отсутствие "паразитных" колечек.
3. Отсутствие колец в вашем случае - это наличие вашего еоф/боф в каждом кольце (т.е. в каждой очереди - если очередей много, то и еоф/боф-оф - много) - как это сформулировать на языке ограничений аксесс - фих знает.
4. Вводя служебный элемент, для которго нот нулл не требуется (рибосому, или "менеджера очереди") - за счет механизма задания ограничения на уровне таблицы (описанном выше), а не поля - вы можете перекраивать очереди (кольца) не снимая ограничений с таблицы. Но от обязанности запретить возможность паразитных колец это вас не освободит. Делать это придется в вба (думается).



ЗЫ: организация очереди присвоением уникального значения из упорядоченного множества (даты-времени, номера, или же некоего дабл значения) снимает проблему возможности возникновения колец (в списках по указателям). Но бесконечная вставка в один интервал потребует рано или поздно сдвига следующих элементов (из за кончности дискрета двоичного представления).