Usa i dati ridondanti nella progettazione del database quando hai più relazioni

È una cattiva pratica denormalizzare come affermi. A seconda dei criteri di ricerca, una qualsiasi delle quattro tabelle potrebbe essere scelta dalla routine di ottimizzazione della query. Se selezioni un package selezionato da un elenco a discesa, non ci dovrebbero essere motivi per aggiungere la tabella packages alla query poiché è possibile far corrispondere il package_id nella tabella package_durations .

Potrebbero esserci motivi per migrare colonne da una tabella a un'altra. Se la durata del pacchetto (start_date, end_date) può essere modificata dopo l'esecuzione degli ordini, potresti voler copiare la durata dell'ordine. Se il priority di un pacchetto può cambiare, copialo nella tabella orders , altrimenti lasciatelo in Tuttavia, migrare le colonne per semplificare la query può portare a problemi.

Sebbene molti strumenti di modellazione assumano come valore predefinito id come nome della chiave surrogata, trovo più utile usare un prefisso basato sul nome della tabella. Ad esempio, usa order_id per la tabella orders ( order è una parola chiave e dovrebbe essere evitata). Avere una tabella order implica che hai un solo ordine, mentre orders implica più di un ordine. È utile se i nomi delle tabelle e delle colonne possono essere utilizzati in frasi che indicano chiaramente le tue intenzioni.