Помогите найти оптимальный вариант хранения данных

Необходимо загрузить в Firebird порядка 2 000 000 аналогов запчастей.
Аналог - это пара "код производителя запчасти, производитель" - "код производителя запчасти, производитель".
Т.е. например:
2101 (ВАЗ) - 234TX (Китайский производитель)
234TX (Китайский производитель) - 3T34 (корейский производитель)

Действует правило "аналог аналога - мой аналог". Т.е. в примере 2101 является аналогом для 3T34 и наоборот.

Вопрос, каким образом организовать оптимальную загрузку и хранение этой информации?
Если хранить "в лоб" пары, то селект будет проходить крайне долго из-за правила "аналог аналога - мой аналог".

Есть другой вариант.
Структура таблицы аналогов:
1. Код товара
2. Производитель
3. ID группы аналогов

Селект из такой таблицы будет работать быстро, но встает проблема с загрузкой данных.
Алгоритм загрузки такой:
1. загружаются все записи в таблицу аналогов
2. каждая пара в соответствии со структурой таблицы разбивается на 2 строки
3. для каждой пары строк задается свой уникальный код группы аналогов
4. после инсерта в таблицу запускается процедура, которая перелапачивает таблицу для определения связей "аналог аналога - мой аналог". Эта процедура обновляет поле с кодом группы аналогов.

Посоветуйте, пожалуйста, как оптимизировать загрузку и хранение данных.

Хотя база данных и Firebird, нo вам, наверное, лучше сюда, так как тема луше вписывается в "Проектирование".

Спасибо за наводку, перенс -)

Если идентификатор детали нормально проиндексируется (т.е. это какой-то уникальный код а не длинная строка) то выборка аналогов по цепочке мне думается может быть вполне быстрой. Это если по конкретной детали вытягиваем ее аналоги а не тянем список деталей с деревом их аналогов.

Vsevolod V
встает проблема с загрузкой данных. Алгоритм загрузки такой:

Странный алгоритм. Входной поток может быть отсортирован? Если да, то можно грузить всё за
один проход, без дополнительных таблиц и процедур.

Posted via ActualForum NNTP Server 1.5

fraks
Если идентификатор детали нормально проиндексируется (т.е. это какой-то уникальный код а не длинная строка) то выборка аналогов по цепочке мне думается может быть вполне быстрой. Это если по конкретной детали вытягиваем ее аналоги а не тянем список деталей с деревом их аналогов.

Так а каким образом определить взаимосвязи этой цепочки?

Dimitry Sibiryakov,

Аналоги грузятся из Экселя либо текстовых файлов.
Аналоги загружаются не единовременно. Т.е. пользователь имеет возможность грузить их по необходимости

Vsevolod V
fraks Если идентификатор детали нормально проиндексируется (т.е. это какой-то уникальный код а не длинная строка) то выборка аналогов по цепочке мне думается может быть вполне быстрой. Это если по конкретной детали вытягиваем ее аналоги а не тянем список деталей с деревом их аналогов. Так а каким образом определить взаимосвязи этой цепочки?

Не понял вопроса. У вас же таблица аналогов? Или я еще чего-то не понял?

create table analog (
id integer not null primary key,
L varchar(20),
R varchar(20)
);

create index analog_L on analog(L);
create index analog_R on analog(R);

Берем детальку, точнее ее код.
Выбираем из analog записи у которых (L=:деталь) or (L=:деталь)
Рекурсивно вытягиваем все цепочки аналогов.
Сортируем, прибиваем повторения, если потребуется.

"Как-то так".

fraks,

Вы все правильно поняли.

Таблица получается такой:

Код 1 Производтель 1 Код 2 Производитель 2 2101 ВАЗ 234TX Китайский производитель 234TX Китайский производитель 3T34 Корейский производитель

Меня беспокоит вопрос, будет ли предложенное вами решение оптимальным на количестве записей в 2 000 000.

Vsevolod V,

Пара определяется по
Код1 = Код2
или по
Код1+Производитель1 = Код2+Производитель2

и какова размерность полей Код* и Производитель*
?