Ottenere le chiavi esterne correlate dalle entità padre

È un cattivo design.

Perché? Non solo è ridondante, ma consente anche incoerenze, ovvero inserisce, aggiorna o cancella le anomalie.

Potresti avere un tagliando di imballaggio che punta a un client diverso da quello a cui punta il suo ordine.

Se ciò accade, una query che si unisce a ORDER recupererà un cliente diverso da una query che non lo fa.

Questo perché stai violando 2NF .

Se vuoi evitare di dover partecipare ogni volta a ORDER , crea una vista e seleziona quella vista. La vista ha ancora l'unione ma non la vedrai.

Nei database non transazionali come i data warehouse, non devi rispettare i normali moduli, ma in un OLTP database come il tuo sembrano essere, avrai un sacco di mal di testa se non lo fai. Ovviamente ci sono delle eccezioni, ma non è il caso con CLIENT , ORDER e PACKING_SLIP .

Generalmente faresti esattamente quello che hai descritto - hai clientId in ORDER e orderId in PACKING SLIP, e unisciti alle due tabelle per ottenere il clientId per lo PACKING SLIP. A meno che tu non abbia un'applicazione davvero performante, o se non hai un numero elevato di ordini, imballaggi o clienti, questo non è un problema.

Se sei veramente preoccupato per le prestazioni, non c'è niente di sbagliato nell'aggiungere clientId a PACKING SLIP, anche se ciò richiederebbe l'aggiunta di codice (o altra logica) per garantire che clientId in PACKING SLIP rimanga coerente con clientId in ORDINE. Questo può essere il migliore in situazioni in cui l'applicazione ha spesso bisogno di accedere a clientId da PACKING SLIP senza ottenere un ORD corrispondente e se si aggiornerà raramente clientId in ORDER.

Idealmente questo sarebbe fatto usando una stored procedure sul lato DB, dove aggiornare un ORDER o aggiungere uno SLIP PACKING sarebbe fatto attraverso una stored procedure che imporrà la coerenza di clientId , ma non sono sicuro se il tuo ORM lo consente. In alternativa, alcuni ORM forniscono un modo per aggiungere tale logica attraverso il codice.