Двусторонние отношения в запросах SQL

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

PartID (PK), int
PartNumber , Varchar (50), Unique
Описание , Varchar (255)

У меня есть требование определить, что определенные части классифицируются как похожие друг на друга. Для этого я установил вторую таблицу, которая выглядит следующим образом:

PartID , (PK) , int
SecondPartID , (PK), int
ReasonForSimilarity , Varchar (255)

Затем между двумя таблицами была установлена ​​связь «многие ко многим».

Проблема возникает, когда мне нужно сообщить о частях, которые считаются похожими, потому что отношения двусторонние I.E. если часть XYZ123 аналогична ABC678 , то ABC678 считается аналогичным XYZ123 . Поэтому, если я хочу перечислить все части, которые похожи на данную часть, мне нужно либо убедиться, что связь установлена ​​в обоих направлениях (что плохо, потому что данные дублируются), либо нужно иметь 2 запроса, которые смотрят на таблицу в обоих направлениях . Мне кажется, что ни одно из этих решений не подходит.

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

Рассмотрим следующие части XYZ123, ABC123, ABC234, ABC345, ABC456 и EFG456, которые были введены в существующую структуру, указанную выше. В итоге вы можете получить данные, которые выглядят следующим образом (без поля причины, которое на данный момент не имеет значения):

PartID , SecondPartID
XYZ123, ABC123
XYZ123 , ABC234
XYZ123, ABC345
XYZ123, ABC456
EFG456, XYZ123

Мой пользователь хочет знать "Какие части аналогично XYZ123 ". Это можно сделать с помощью такого запроса:

SELECT SecondPartID
FROM tblRelatedParts
WHERE PartID = 'XYZ123'

Проблема в том, что он не выберет часть EFG456, которая связана с XYZ123, несмотря на то, что части были введены наоборот. Вполне возможно, что это может произойти в зависимости от того, с какой частью в данный момент работает пользователь, и отношения между частями всегда будут двусторонними.

Проблема, с которой я столкнулся, заключается в том, что теперь мне нужно проверить, что, когда пользователь устанавливает связь между двумя частями, она еще не существует в другом направлении.

@Goran

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

Данные, перечисленные выше, вводятся в новую таблицу (обратите внимание, что я изменил partID на номер детали, чтобы сделать пример более понятным; семантика моей проблемы не изменилась)

Таблица будет выглядеть следующим образом :

RelationshipID , PartNumber
1, XYZ123
1, ABC123
2, XYZ123
2 , ABC234
3, XYZ123
3, ABC345
4, XYZ123
4, ABC456
{ {1}} 5, EFG456
5, XYZ123

Затем я могу получить список похожих частей, используя такой запрос:

SELECT PartNumber
FROM tblPartRelationships
WHERE RelationshipID ANY (SELECT RelationshipID
                          FROM tblPartRelationships
                          WHERE PartNumber = 'XYZ123')

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