Компактный индексный формат Visual FoxPro - PullRequest
3 голосов
/ 31 декабря 2008

Я пытаюсь понять формат файла компактного индекса Visual FoxPro (* .IDX). В настоящее время я обращаюсь к документации Microsoft для получения рекомендаций.

Индекс представляет собой B-дерево из 512-байтовых узлов. Каждый листовой («внешний») узел содержит несколько записей. Каждая запись состоит из четырех частей данных:

  • Номер строки [ФИКСИРОВАННАЯ ДЛИНА]
  • Дублирующее количество байтов (документация не объясняет этого) [ФИКСИРОВАННАЯ ДЛИНА]
  • Количество завершающих байтов (документация не объясняет этого) [ФИКСИРОВАННАЯ ДЛИНА]
  • Ключ [ПЕРЕМЕННАЯ ДЛИНА]

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

  • 24-байтовый заголовок
  • номер строки, количество повторяющихся байтов, число завершающих байтов (запись # 1)
  • номер строки, количество повторяющихся байтов, число завершающих байтов (запись № 2)
  • номер строки, количество повторяющихся байтов, число завершающих байтов (запись № 3)
  • ...
  • ключ (запись № 3)
  • ключ (запись № 2)
  • ключ (запись № 1)

Как определить индивидуальную длину клавиш? В документации не указывается это. Они идеально соприкасаются (без нулевых разделителей).

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

Я считаю, что форматы файлов FoxPro являются производными от стандарта xBase. Возможно, это звонит в колокол?

Ответы [ 4 ]

4 голосов
/ 02 января 2009

После обнаружения модуля Perl XBase :: Index я определил, что ключи во внешнем узле фактически имеют ту же длину, что и ключи фиксированной длины, найденные во внутренних узлах, за исключением того, что удаляются все конечные пробелы. Это то, к чему относится «число конечных байтов», упомянутое в документации (сколько конечных пробелов было обрезано с конца ключа). Я до сих пор не определил, что такое «повторяющийся счетчик байтов», но модуль, по крайней мере, уточнил свои отношения:

variable_key_length = fixed_key_length - duplicate_byte_count - trailing_byte_count

Например, предположим, что фиксированная длина ключа для этого индекса была 10 байтов. Теперь предположим, что ключ «DOG» был сохранен во внешнем узле. Число повторяющихся байтов (в соответствии с тем, что я наблюдал), скорее всего, будет равно нулю, а число завершающих байтов равно 7 (количество пробелов сокращено). Следовательно, будут сохранены только три байта, представляющие «СОБАКУ».

1 голос
/ 18 июня 2011

В Xbase индексирование редко превышает 10 символов или 15 (редко) при использовании индексов (индекс, обсуждающий тексты).

В любом случае, если вы знаете, какое количество ключей пропорционально делит двоичную часть. Когда вы создаете алгоритм, который хранит данные, или сохраняете данные, используя: начальные или конечные маркеры или вкладки, или вы оставляете статический размер, чтобы не использовать оставленный пустой Статический формат менее эффективен, но обеспечивает большую скорость чтения и, очевидно, создает более предсказуемые структуры.

1 голос
/ 22 октября 2009

О повторяющемся числе байтов: это означает количество первых байтов, которые одинаковы в текущем и предыдущем ключах. Первая ключевая запись, хранящаяся в конце узла, имеет полную длину, кроме конечных пробелов; последовательный ввод ключа имеет только символы, отличные от предыдущего ввода ключа.

0 голосов
/ 01 января 2009

Microsoft говорит о структуре файла IDX (а внизу страницы есть ссылки на все остальные, например Компактный индексный формат .)

...