orefkov писал(а) 26. Октября 2007 :: 09:23:

Да ладно! Стоял человек на некотором элементе, собирался с ним работать. А тут из-за твоих представлений о том, как должны работать табличные поля, элемент пропал с глаз долой. Так что не все так просто, как тебе кажется. В разных случаях нужно разное поведение.

Uzhast писал(а) 26. Октября 2007 :: 08:52:

Скажу тебе по секрету, что когда работаешь с SQL-сервером, для любых действий надо делать запрос.
И зря ты думаешь, что такой запрос напряжет сервер. Он, сука, умный, и поймет, что от него хотят всего-лишь seek and skip. [/quote]
Может быть. А, может, и нет. Зависит от сервера. И, в любом случае, вместо прозрачного алгоритма работы с данными получаем крокодила.

orefkov писал(а) 26. Октября 2007 :: 09:29:

Орефков, ну это уже не смешно. Честное слово. Ну ты же всегда был умным мужиком. А сейчас мне тебе приходится объяснять элементарные вещи. Мне же неудобно. Ты же вроде авторитет, а простых вещей не знаешь. Может, лучше в личку перенести обсуждение?

Я перехожу по физическому номеру записи на нужную. Далее я делаю SKIP в нужном направлении. Как работает SKIP? Вот так:
Цитата:

Вкуриваешь? Фактически, номер записи - это закладка. Вот и все.

Uzhast писал(а) 26. Октября 2007 :: 09:34:

Ты мануалы-то не только читай, мозг включай иногда
Полезно иногда подумать, как же работает это волшебство.
Номер записи - это закладка в файле, но никак не в ИНДЕКСЕ.
Так  что скорее всего, унутре все происходит так:
Когда ты делаешь GOTO номер, фокс позиционирует указатель в файле-ДАННЫХ на нужную запись.
После этого, если для таблицы установлен порядок обхода по индексу, ему просто НЕОБХОДИМО перепозиционировать указатель в файле-ИНДЕКСЕ на узел, СООТВЕТСТВУЮЩИЙ ЭТОЙ ЗАПИСИ В ИНДЕКСЕ.
Иначе откуда он будет делать дальнейший SKEEP ?
Как это делает Фокс?
Есть такая инфа?
Скорее всего он формирует индексный ключ записи, на которую он перешел в ФАЙЛЕ, и ищет этот ключ в ИНДЕКСНОМ ФАЙЛЕ. При этом, если ключ не уникален, ему приходится НЕМНОЖКО ПРОСКАНИРОВАТЬ индекс в пределах этого ключа, чтобы точно найти тот узел, в котором номер записи соответствует номеру записи, на который он перешел в файле.
А это оптимальней всего делать, когда неуникальные ключи в индексе еще дополнительно упорядочены по номеру записи.
Что собственно, меня и интересовало.
И что собственно, мы видим на практике - действительно, неуникальные ключи в индексном файле идут в порядке физических номеров. И так как мои логические построения привели к тому-же выводу, что и существуюет на практике, то в них скорее всего большая доля истины, чем в бездумном цитировании мануалов.
PS
И скореевсего поэтому ключ в cdx-файле лежит в виде строки
СамКлюч + (Четыре символа - номер записи в hex-нотации)

Uzhast писал(а) 26. Октября 2007 :: 09:27:

Вот именно - в ТП исчезнет ТОЛЬКО элемент, измененный другим юзером.
А в 1С на курсорах - и этот элемент исчезает, и соседние начинают вести себя крайне неадекватно.

Цитата:

Можно и левое ухо правой рукой чесать
Никто не спорит, что такое дерево можно построить.
Но во закавыка - в cdx-файле его нет. Какая жалость.
А делать его в памяти?
Ну, в однопользовательской среде почемы бы и нет, для небольших файлов.
Но стоит только вспомнить, что файл могут редактировать несколько юзеров, и становится сразу понятно, что дерево в памяти здесь не поможет.
Так что продолжай зубрить мануалы и верить в волшебников.

Uzhast писал(а) 26. Октября 2007 :: 10:06:

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

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

Но не надо торопиться.
Возможно стоит сделать некоторые тесты, которые подтверждают эффективность или неэффективность определенного подхода для DBF.

Скажем, для SQL мне не удалось для упорядочивания и для поиска (т.е. при проверке идеи разделения функций ключей) получить два Index Seek.
Только Index Seek + Index Scan.
Либо Index Scan + Bookmark lookup по индексу упорядочивания.
Это для двух индексов - уникальному (для позиционирования) и неуникальному для упорядочивания.

Для ИТ позиционирование в индексе по номеру физической записи - это также index scan, либо вычисление ключа + index seek + небольшой scan.

SQL, кстати, также мог бы делать index seek + index seek + небольшой scan, но не хочет.

Как обстоят дела для DBF - надо исследовать.
По вашей дискуссии однозначные выводы сделать пока нельзя - значит не надо ее завершать на полдороге.


_{P.S.
Разбив шахматную доску о голову оппонента сложно выиграть партию.
У меня обычно не получалось, даже когда я был абсолютно прав.}

Uzhast - ты меня извини, но я в этом споре поддерживаю Орефкова. Ибо его точка зрения для меня более убедительна. Например тот алгоритм, про который ты говоришь "шаткое предположение" - совпадает с тем, который реализовал бы я, если б мне пришлось решать подобную задачу.