Каковы передовые практики с первичными ключами и бизнес-идентификаторами для элементов в предложениях JOIN SQL-заказов SELECT, UPDATE или DELETE?

Мы предоставляем через веб-сервисы и функции в слоях ГИС некоторые данные, поступающие из таблиц нашей базы данных. Каждая запись, «элемент», имеет бизнес-идентификатор, который наш вызывающий может использовать для нацеливания на определенные элементы, когда ему нужно что-то с ними сделать или попросить узнать о них что-то. По многим причинам, не перечисленным здесь, возврат технических идентификаторов (например, первичных ключей) запрещен.

Итак, когда мы получаем запрос вызывающего абонента, мы запускаем запрос SQL следующим образом:

SELECT * FROM customer c 
 WHERE c.customer_number = ... 

Но когда придет время, когда этот запрос должен быть завершен некоторыми пунктами JOIN, что лучше всего сделать? Присоединиться к базовым таблицам по их бизнес-идентификатору?

SELECT * FROM customer c, purchase_order po 
 WHERE c.customer_number = ...
  AND po.customer_number = c.customer_number

или обеспечить точность, сохранив ссылки с первичными ключами?

SELECT * FROM customer c, purchase_order po 
 WHERE c.customer_number = ...
   AND po.customer_id = c.id

В начале жизненного цикла приложения, конечно, бизнес-идентификатор будет уникальным, как и первичный ключ основной таблицы, описывающей их элемент (но не с той же последовательностью, не с такими же значениями) .
Но кто может сказать, что произойдет через три года? То, что когда-то было отношением 1 - 1, могло стать отношением 1 - п, и бизнес-идентификатор, который был уникальным в таблице, здесь больше не является уникальным.

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

Спасибо !