Un pedido siempre tendría un cliente, ¿no? Por lo tanto, no es una combinación izquierda sino interna.
Lo que los vincula es el customer_id. Entonces su SQL es simplemente:
select o.order_number, o.customer_ID, o.address,
c.first_name, c.last_name
from orders o
inner join customer c on o.customer_ID = c.customer_ID;
Relación de entidad:
Pedido ClienteCustomer_Id 0...N>---+ 1 Customer_Id... ...
Esta relación EF es de la base de datos de muestra de MS SQL Server Northwind. En esa base de datos de muestra, al igual que la suya, hay Clientes y Pedidos. Las tablas Clientes y Pedidos están relacionadas a través de los campos CustomerId en ambas tablas (es la clave principal en Clientes y la clave externa en la tabla Pedidos). Cuando modela eso como una relación de Entidad, tiene el diagrama anterior. La entidad del cliente tiene una propiedad de navegación "Pedidos" (a través de customerId) que apunta a los pedidos de un cliente en particular. Y la entidad Pedido tiene una propiedad de navegación que apunta a su Cliente (nuevamente a través de CustomerId). La relación es 1 a 0 o muchos (1 - *), lo que significa que un Cliente puede tener 0 o más Pedidos.
Cuando realiza la unión desde el lado del Cliente, utiliza una unión IZQUIERDA "si desea ver a todos los Clientes, independientemente de si tienen Pedido (s) o no":0 o más Pedido (s). Si desea ver solo aquellos con pedido(s), utilice una combinación interna.
Cuando realiza la unión desde el lado de los Pedidos, entonces un Pedido debe tener un Cliente, por lo que no puede ser una unión IZQUIERDA. Es una unión INTERNA.
Puede verificar la relación de ambos lados usando el campo de conexión CustomerId.
No tendría una tabla separada para "OrderId, CustomerId" ya que no es una relación de muchos a muchos (sería pura redundancia y crearía anomalías de normalización).
Espero que sea más claro ahora.
