Данные длиною в три байта.

← →
KilkennyCat © (2005-05-10 12:49) [0]

Можно ли такое реализовать?
Предположим, что куча записей базы данных имеют ссылку на другую базу. В этой другой базе записей не более $ffffff, то есть, в первой базе достаточно хранить ссылку размером в три байта. При миллионе записей в первой базе отсутствие одного байта - почти мегабайт экономии.

← →
KilkennyCat © (2005-05-10 12:53) [1]

Прошу прощения, как-то пространно написал. Проще говоря, как считать (например, из файла) три байта и привести их к LongWord?

← →
Marser © (2005-05-10 13:03) [2]

longwordvar:= firstbyte + secondbyte shl 8 + thirdbyte shl 16

← →
GreatMaster (2005-05-10 13:04) [3]

asm
xor eax, eax
mov al, число1
shl eax, 16
mov ah, число2
mov al, число3

результат в eax :)

← →
KilkennyCat © (2005-05-10 13:05) [4]

Спасибо.
Сейчас еще 0D0A выкину, и моя база будет самая малюсенькая! :)

← →
Marser © (2005-05-10 13:08) [5]

Это пример приведения трёх байт к LongWord. Ну а считывать можено обратной операцией.
firstbyte:=lo(longwordvar);
secondbyte:=hi(longwordvar);
thirdbyte:=longwordvar shr 16

← →
nikkie © (2005-05-10 13:12) [6]

мегабайт экономии, говоришь? на гигабайтной базе вряд ли заметишь. надо считать относительный выигрыш, а не абсолютный.

← →
kai © (2005-05-10 13:13) [7]

KilkennyCat © (10.05.05 13:05) [4] Спасибо.
Сейчас еще 0D0A выкину, и моя база будет самая малюсенькая! :)
и самая медленная -)

← →
KilkennyCat © (2005-05-10 13:17) [8]

> [5] Marser © (10.05.05 13:08)

ага, это я понял из [2], спасибо.

← →
KilkennyCat © (2005-05-10 13:20) [9]

> [6] nikkie © (10.05.05 13:12)

Как сказать... Переделка KLADR таким макаром позволила с 7,72 М в архиве уменьшить до 2,5 М в архиве. Что уже существенно при скачивании в интернете.

> [7] kai © (10.05.05 13:13)

Быстрее, чем через BDE

← →
GreatMaster (2005-05-10 13:23) [10]

Marser, [2] даст не верный результат, если твои переменные байтовые! (firstbyte, secondbyte, thirdbyte : byte;)
надо по очереди сдвигать:
a:=1;
a:=a shl 8;
a:=a + 2;
a:=a shl 8;
a:=a + 3;

← →
Anatoly Podgoretsky © (2005-05-10 13:32) [11]

KilkennyCat © (10.05.05 12:49)
Ты гораздо больше выиграешь если объединишь эти две базы.

← →
nikkie © (2005-05-10 13:38) [12]

>с 7,72 М в архиве уменьшить до 2,5 М в архиве
в 3 раза за счет удаления 1 байта из 4-х?
даже если других данных в базе нет - выигрыш только 25% будет, а не 66%.
что-то мне с трудом верится.

← →
KilkennyCat © (2005-05-10 13:43) [13]

> Anatoly Podgoretsky © (10.05.05 13:32) [11]

Нет, при объединении я буду вынужден вместо трех байтов добавить намного больше.

> nikkie © (10.05.05 13:38) [12]

Это не единственная оптимизация.

← →
GreatMaster (2005-05-10 13:54) [14]

Держи SmallInt + Byte
ещё и за счёт служебных данных пару бит выиграешь :)

← →
nikkie © (2005-05-10 14:11) [15]

>Это не единственная оптимизация.
вооот. осталось теперь оценить вклад именно этого момента в общий результат. сдается мне, что в этой базе есть также и текстовые данные, а потому вряд ли экономия одного байта даст более 1% выигрыша.

← →
GreatMaster (2005-05-10 14:33) [16]

голое поле номеров никому не нужно, тогда бы как Anatoly Podgoretsky сказал и всё.
ясный перец есть чёто ещё. это или такие же 3х байтовые поля-обрезки на другие/этуже таблицы, тогда изврат с 3мя байтами канает. Или просто обычные данные, тогда замутка ваще не в тему и выигрыш --> 0

> nikkie © (10.05.05 14:11) [15]

Да есть.

Ну раз уж заговорили оффтопом, давайте тогда расскажу вкратце структуру. Может, придем к выводу, что я фигню наворотил.
Итак, популярный KLADR имеет три основных файла:
KLADR.DBF, где находятся следующие мне интересные поля:
наименования городов, районов и пр. (string), код субъекта(byte), почтовый индекс (string[6]), окато(string[11]), код налоговой (string[4]), сокращенное наименование (string[1-10])
STREET.DBF c аналогичной структурой, DOMA.DBF, SOCR.DBF

В каждом есть еще громадное поле CODE (11, 15 и 23 байтов), которое все связывает.

Что сделал я - выдрал все поля и уничтожил дубликаты.
Получил в итоге семь файликов: файл связей, индексы, окато, гни, наименования, сокращенные наименования, расшифровка наименований.
Всего в дбэфах около миллиона записей (а ведь в каждой записи еще кучка полей...), объем базы около 50 метров (изначально было почти 70, но я выкинул ненужных полей немного :) ).

У меня:

файл - число записей - необходимый размер ссылки
DOMA - 23911 - 2byte
INDEX - 40227 - 2byte
NAME - 152028 - 3byte
SOCR - 81 - byte
SSOCR - 81 - ненужно
OKATO - 129128 - 3byte
Region - 99 - byte
GNI - 2493 - 2byte

итого, мой CODE имеет размер 14 байт.

число записей файла связей около 600 тысяч.

все файлы в несжатом виде имеют размер около 11 метров

Сделав NАМЕ и ОКАТО на один байт меньше, я выиграл чуть больше мегабайта. Заменив $0D0A на $00 я выиграю еще почти 0,4 метра

Проигрыш в работе только лишь при первоначальной загрузке. И вполне терпимый, по крайней мере, я это торможение (4 секунды) заметил лишь на Pentium-II-300

Согласитесь, отобрать у 11 метров еще полтора - это неплохо.
Но это еще не конец: файл связей вполне поддается алгоритмизации, а не тупой прописи. Ща еще уменьшу вполовину.

>объем базы около 50 метров
>все файлы в несжатом виде имеют размер около 11 метров
если честно, то я не понимаю.

>итого, мой CODE имеет размер 14 байт.
>число записей файла связей около 600 тысяч.
видимо один файл CODE весил 11Mb? его удалось сократить на 1/8 (2 байта из 16). ок. а что с остальными 40Mb?

> nikkie © (10.05.05 16:23) [19]

остальные - это структура dbf и многократно, сверхмногократно повторяющиеся значения.

если кто-нибудь понял, объясните мне.

> nikkie © (10.05.05 16:50) [21]

гм...

ну вот, к примеру имеем таблицу. Стандартно, как в книжке :) - три отдела сотрудников, фио сотрудников, номер телефона сотрудников. Но телефон на всю контору - один единственный и фио1 работает сразу в двух...
Так вот кладр был бы так:

отдел1 фио1 телефон1
отдел1 фио2 телефон1
отдел2 фио1 телефон1

у меня же было бы так:

файл с пятью записями отдел1, отдел2 , фио1 , фио2, телефон1
и файл связей, реализовавший бы первоначальную таблицу.

ну вот опять из статистики: почтовый индекс в кладре реализован как строка из 6 байтов и пишется в каждой записи, которых более миллиона. Но на самом деле почтовый индекс можно выразить всего тремя байтами, и всех вариантов индекса будет 999999*3 = 2,8 метра. Однако, так как вместо индекса мы вынуждены поставить идентификатор, то выигрыша никакого. Но! всего вариантов индекса 40227, т.е максимальный объем около 300 килобайт, и тогда мы получаем уменьшение объема индексов в таблице в два раза + 300 кил. Фактически с 5.7 метров до 3 метров.

Кстати, связи имеют четкую древовидную структуру. Это позволяет опять их оптимизировать по объему и значительно по скорости работы, так как на поиск подчиненых объектов уже не требуется полный перебор.
Да здравствует мой вариант КЛАДРа! :)

Данные длиною в три байта. Найти похожие ветки