ernestosup ha scritto:
Tabella anagrafica: ID, Cognome Medico, Nome medico, indirizzo medico, numero civico, CAP, Città
OK, anche se, leggi dopo, io scriverei IDPersona, Cognome, Nome, ecc...
ernestosup ha scritto:
Tabella prezzi: ID, Descrizione lavoro, Costo. (puoi suggerirmi come rendere modificabili i prezzi che variano nel tempo ?)
Trovo che sarebbe più giusto chiamare la tabella DescrizioniLavori piuttosto che Prezzi perchè è dei primi che si parla principalmente. I loro relativi prezzi...ripeto non vanno gestiti lì.
ernestosup ha scritto:
Il campo cognome medico della tabella anagrafica è collegato uno - molti con cognome medico della tabella lavorazioni
Non è consigliato usare il solo campo Cognome per relazionare 2 tabelle. Se malauguratamente avessi 2 medici con lo stesso Cognome avresti problemi. Il campo IDPersona (sicuramente univoco) deve essere chiave primaria.
Analogamente ci vedrei un campo IDCliente nella tabella Lavorazioni.
ernestosup ha scritto:
il campo descrizione del lavoro è preso con una casella combinata da tabella prezzi
Mi stai dicendo che non c'è la relazione uno-a-molti?
ernestosup ha scritto:
Tabella lavorazioni: ID, Cognome medico, Cognome cliente del medico, Data ricevimento lavoro, Descrizione lavoro, Quantità, data Consegna lavoro...
...Un secondo operatore dovrà operare su una maschera contenente tutti i dati precedentemente trascritti, con l'aggiunta automatica del campo costo, e dovrà potere inserire in un altro campo che chiamo "correttivo" un valore che corregge eventualmente il costo.
Di conseguenza dovrà avere automaticamente il campo calcolato "Nuovo prezzo" (costo+correttivo) e il campo calcolato "Importo" (Quantità x Nuovo prezzo)
Qua c'è molto caos. Le tabelle sono concepite per essere i contenitori dei dati più indispensabili al database. Per dati indipensabili intendo dire solo quelli che, se non c'è l'utente a metterli, nessun altro glieli può dare. Per tutti i campi che sono frutto di calcolo, espressioni derivate e quanto altro, a questa incombenza provvedono soprattutto le query e, in taluni casi, alcune caselle di testo nelle maschere.
Ti consiglio di nominare tutti i campi ID in maniera appropriata per non avere future ambiguità. Quindi IDPersona, IDLavorazione. Il campo IDDescrizioneLavoro si potrebbe omettere in quanto DescrizioneLavoro risulterebbe sicuramente univoco, quindi può essere eletto chiave primaria.
Riepilogando le relazioni, io ci vedrei le seguenti:
Anagrafica.IDPersona uno-a-molti con Lavorazioni.IDMedico
Anagrafica.IDPersona uno-a-molti con Lavorazioni.IDCliente
DescrizioniLavori.DescrizioneLavoro uno-a-molti con Lavorazioni.DescrizioneLavoro
Mi fermerei qui per ora. Vorrei che tu prendessi coscienza del nuovo assetto tabelle e campi.