Carmine Sepe ha scritto:
Questo db mi serve per gestire gli ordini che arrivano quotidianamente, non per gestire i contratti di appalto (ad avercene bisogno di un db per gestire contratti
per cui le caratteristiche del contratto, in questo momento, le posso tranquillamente associare direttamente al cliente, in quanto questo db mi servirà in produzione.
Sei libero di progettarlo anche così, ma considera che se la Scuola Marconi nel 2010-2011 ha scelto un certo Turno+Packaging e nel 2015-2016 un altro, tu vai a modificare qualcosa che poi ritroverai INCOERENTE nel corso "storico". Forse questi 2 valori ti tornano utili per "pilotare/controllare" l'input dati degli orari Ordini/Pietanze che dovrai comunque tracciare a parte...altrimenti combini "pasticci".
P.S.: Ripensandoci. Ho capito che non vuoi ritrovarti una tabella Contratti IN MEZZO. Potresti comunque tenerla A PARTE e gestire così:
Clienti uno-a-molti Ordini (per non guastare la struttura base)
Clienti uno-a-molti Contratti (te la tieni come memorandum storico)
N.B.: Il titolo che hai proposto inizialmente, durante il prosieguo della discussione, ha preso tutta un'altra direzione. Ne avremmo discusso meglio nella sezione "Progettazione database". Nulla di grave, va bene anche così.
Se la struttura tabelle ti sta bene così, questa discussione può dirsi conclusa. Per altre problematiche, apri nuove discussioni (un problema=una discussione).