Доброго времени суток!

Немного оффтоп, так как это не совсем 1с, но вопрос важный для организации структуры.

Исходное:
Есть БД запчастей(зч). У каждой зч есть аналог. Каждый аналог имеет свой аналог, который может "замкнуться" на зч с корой начался поиск.
На данный момент, всё храниться в двух таблицах зч и азч(аналоги), где большое количество дублей.
Рост номенклатуры ведет к снижению скорости.

Ожидаемый результат:
Структура БД, где решается проблема роста. Планируемая структура таблиц ориентировочно:
1 запчасти
2 аналоги (сопоставление id из таблицы 1 + таблица 3)
3 производители
4 категории запчастей

Если использовать как есть, то можно получить рекурсию. Избежать её можно через создание "временной таблицы" (представления), где есть уникальный ключ создаваемый из "номер запчасти" + "бренд". Т.е. одна зч не может быть выбрана два раза. Вложенный запрос будет останавливаться при штатном окончании или повторении ключа "номер запчасти" + "бренд".

Прошу комментарии по теме: насколько верен такой подход? Есть ли стандартные решения для реляционных БД?
Какие могу быть подводные камни?

(0) Верен
Но вообще лучше еще дополнительно ограничить вложенность рекурсии, потому что я слабо представляю себе менеджера, объясняющего покупателю, как его колодки через 18 замен на аналоги превратились в лобовуху

(0) Для начала надо решить "вассал моего вассала не мой вассал" или нет?
В смысле "аналог моего аналога мой аналог" или нет?

Допустим есть три запчасти/детали
Для 1-й аналогами являются 2-я и 3-я
Для 2-й аналог только 3-я
А для 3-й аналог только 1-я

У вас такая ситуация или все же все 3 запчасти полные взаимозаменяемые аналоги друг друга?
А что в базе кривизна так это просто ошибки и недостаток инфы

(2)+ Если все запчасти полные аналоги - то логично можно упростить структуру СУБД
Просто выделить эти уникальные "классы" (группы) аналогов, и для всех запчастей указывать как аналоги не конкретные запчасти а id группы

(2) (0)

Типа
Первая запчасть -- оригинал
Вторая запчасть -- как оригинал, но Китайский
Третья запчасть -- как оригинал, но Китайский и вместо 4-х крепежных отверстий только 3

:-)

(4) Поэтому и спрашиваю ТС
В любом случае можно перейти на группы/классы аналогов
И отношения между ними по взаимозаменяемости

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

(1) Спасибо. Ограничивать вложенность, была такая мысль. Планирую провести натурный эксперимент, что бы точно понимать уровень возможной вложенности и скорость работы.

(2) Такой вариант более чем возможен. Позиций много и аналоги заносят люди или автоматическая подгруздка из сторонних источников.

(3) Как раз все не просто, в том числе с именованием производителей.

У ildarovich'а на инфостарте как раз есть аналогичный пример с запросом на иерархию  (граф технологической карты, или типа того) с проверкой на зацикленность графа

(4) маловероятно, подобные данные проходят почти "ручной" контроль (в т.ч. фото) и первый возврат вноситься в БД, как не валидный.

https://infostart.ru/1c/articles/160707/

Держите. Все бы вам рекурсию тулить.

Процедура ПолучитьАналогиНаСервере(Запчасть)
		
	ВладельцыАналогов=Новый Массив;
	ВладельцыАналогов.Добавить(Запчасть);

	МенеджерВТ=Новый МенеджерВременныхТаблиц;
	Запрос=Новый Запрос;
	Запрос.МенеджерВременныхТаблиц=МенеджерВТ;
	Запрос.Текст=
	"ВЫБРАТЬ
	|	Запчасти.Ссылка КАК Запчасть
	|ПОМЕСТИТЬ ОбработанныеЗапчасти
	|ИЗ
	|	Справочник.Запчасти КАК Запчасти
	|ГДЕ
	|	Запчасти.Ссылка В(&ВладельцыАналогов)
	|
	|ИНДЕКСИРОВАТЬ ПО
	|	Запчасть";
	Запрос.УстановитьПараметр("ВладельцыАналогов",ВладельцыАналогов);
	Запрос.Выполнить();
	Запрос.Текст=
	"
	|
	|////////////////////////////////////////////////////////////////////////////////
	|ВЫБРАТЬ
	|	АналогиЗапчастей.Запчасть КАК Запчасть
	|ПОМЕСТИТЬ НайденныеАналогиЗапчастей
	|ИЗ
	|	Справочник.Запчасти.АналогиЗапчастей КАК АналогиЗапчастей
	|ГДЕ
	|	АналогиЗапчастей.Ссылка В(&ВладельцыАналогов)
	|	И АналогиЗапчастей.Запчасть.ПометкаУдаления = ЛОЖЬ
	|	И НЕ АналогиЗапчастей.Запчасть В
	|				(ВЫБРАТЬ
	|					ОбработанныеЗапчасти.Запчасть КАК Запчасть
	|				ИЗ
	|					ОбработанныеЗапчасти КАК ОбработанныеЗапчасти)
	|;
	|
	|////////////////////////////////////////////////////////////////////////////////
	|ВЫБРАТЬ
	|	НайденныеАналоги.Запчасть КАК Запчасть
	|ДОБАВИТЬ ОбработанныеЗапчасти
	|ИЗ
	|	НайденныеАналогиЗапчастей КАК НайденныеАналоги
	|;
	|
	|////////////////////////////////////////////////////////////////////////////////
	|ВЫБРАТЬ
	|	НайденныеАналогиЗапчастей.Запчасть КАК Запчасть
	|ИЗ
	|	НайденныеАналогиЗапчастей КАК НайденныеАналогиЗапчастей
	|;
	|
	|////////////////////////////////////////////////////////////////////////////////
	|УНИЧТОЖИТЬ НайденныеАналогиЗапчастей";
	Аналоги=Новый Массив;
	Пока Истина Цикл
		Запрос.УстановитьПараметр("ВладельцыАналогов",ВладельцыАналогов);
		
		ТаблицаРезультата=Запрос.Выполнить().Выгрузить();
		Если ТаблицаРезультата.Количество()=0 Тогда
			Прервать;
		КонецЕсли;
		НайденныеАналоги=ТаблицаРезультата.ВыгрузитьКолонку("Запчасть");
		ВладельцыАналогов=НайденныеАналоги;
		Для Каждого Аналог Из НайденныеАналоги Цикл
			Аналоги.Добавить(Аналог);
		КонецЦикла;		
		
	КонецЦикла;
	
КонецПроцедуры

(10) есть риск бесконечного зацикливания

(2)+ "Сколько стоит капля пива? -Нисколько -Тогда накапайте кружечку".
Я бы рекурсию вообще исключил. Тогда это регистр сведений.
Кстати: если Б аналог А, то А - аналог Б? Скорее всего, да, поэтому РС можно сократить вдвое.

(12) далеко не всегда "аналогия" симметрична

(13) Тогда РС в 2 раза больше. Измерения: Оригинал и Аналог.
В симметричном случае можно было бы вместо 2-х записей (А,Б) и (Б,А) хранить одну, например, (А,Б). Но работать с ним сложнее.
(0) Я бы не морочился с рекурсией - высока вероятность натолкнуться на неполноценную замену. А экономия на регистре не слишком велика.

(14) Симметричные случаи очень редки, поэтому на них ориентироваться не стоит. Поэтому РС с измерениями "Оригинал" и "Аналог" и текстовым ресурсом "Условия замены".

(9) Думаю, это то что нужно, но умишка не хватает(( Буду вчитываться. Спасибо.

(10) Спасибо! За интересный пример. Но решение хоть и для 1с, но на внешней базе, так как будут и другие пользователи.

(2) Извиняюсь. Был не прав в (6). Всё что в цепочке, всё считается аналогом Если А-Б, Б-В, то А-В.

(16) 1.Рекомендую вообще с его статейками поразбираться. Много вкусного
3. Не всегда аналоги симметричны. какая-нибудь "запчасть" "с четырьмя отверстиями" может быть аналогом запчасти "с тремя отверстиями", но не наоборот.

(16) "Но решение хоть и для 1с, но на внешней базе, так как будут и другие пользователи. "

Непонятна релляция, возникшая в вашем сознанании.

(18) Это классика же
Берется нечто вроде PostgreSQL, там создаются таблички и пишется код работы с ними из 1С
Через ВИД или еще как
Причем даже добавлять записи можно через ВИД (извратом через хранимки)

Так как БД внешняя относительно 1С - с ней могут работать иные системы, не только 1С
И сервисы в 1С ваять не надо

(1) я бы сделал коэффициент подобия от 0 до 1, и при каждом рекурсивном вызове коэффициенты умножал на произведение предыдущих. И далее если например коэффициент подобия менее 0.65 то не рассматривать как аналоги.

А вообще, конечно, прикольно было бы поиметь тестовые данные, чтоб покрутить...

(18) Извиняюсь. Тут ясная структура, подходящая для любой БД.

(19) Да. Eже есть работающий набросок REST API для MSSQL. Позволит его использовать из 1С без драйвера, что упростит работу с модулями, когда данные можно разсовывать только по комментариям и прочим полям.

(17) Да. Это довольно интересно вспоминать составление матриц смежности. Практики в институте не было, за то с математикой было хорошо) Симметрия аналогов очень больная тема, руководитель отдела сказал, что все должно быть симметрично иначе утонем. Так что изучаю транзитивное соединение)

(20) Составлять коэффициенты на сотни налогов из сотен тысяч позиций довольно затруднительно. Потребность только подходит/не подходит.

(0) На чём Вы собираетесь сэкономить за счет рекурсии? На числе записей (Оригинал, Аналог)? Ну сэкономите раза в 3-4 и получите геморрой с проверкой на цикличность и выдачей неверных аналогов.

(22)
> Составлять коэффициенты на сотни аналогов из сотен тысяч позиций довольно затруднительно. Потребность только подходит/не подходит.

Но ведь прикольно! Аналог на 76% Отмазка опять же - "вы же знали, что приобретали не полный аналог!"

(24) Угу и коэффициенты "аналоговости" по отзывам средним арифметическим составлять