Ciao tornu,
grazie dell'attenzione, si sono guarito più o meno. Ci avrei giurato che non t'andava bene
Scherzi a parte, sapevo di certe lacune nei campi delle tabelle, ma pensavo che fosse sufficiente dare l'idea, magari spiegando alla fine quali lacune.
Mi scuso per non essermi spiegato meglio già ieri ma è così difficile anticipare quello che si vuol fare quando noi stessi non lo abbiamo ancora capito.
Forse non dovevo scegliere come database la sola parte ordine di un gestionale, ma nella mia ignoranza mi sembrava che essa rappresentasse bene i vari aspetti essenziali utili a spiegare cosa sono le relazioni e cioè i dati aggregati (tabelle) e le varie relazioni fra le aggregazioni e nell'aggregazione stessa.
Forse qui sbaglio ed è appunto per questo che ho chiesto aiuto proprio a voi che ne masticate, se non essenziali alla dimostrazione certi particolari mi parevano superflui, ma ripeto è da un po di giorni che metto e tolgo e allora...
Via, cap, provincia ecc. mi sembravano ovvi è per questo che non li ho inseriti, anche la scelta degli idraulici l'ho fatta proprio per semplificare e nell'immaginario non abbisognano di grandi attrezzature anche se poi non è così vero.
Rimanendo alla tabella clienti, se volessimo farla nei canoni allora non dovremmo scartare il sistema di inserire le colonne tel1 e tel2, perché nei gestionali “veri” forse sarebbe più utile mettere una tabella a parte per i contatti e un'altra per i dispositivi di contatto in quanto a priori non possiamo sapere se un nostro contatto ha più addetti agli acquisti e quanti telefoni e telefonini fax e-mail siti e le prossime diavolerie che si inventeranno ecc.
Ci sarà il cliente che ha un solo telefono niente telefonini mail fax e quello che avrà 10 addetti con 5 dispositivi l'uno e allora se prevediamo troppo avremo troppi campi vuoti e viceversa non basteranno e non potremmo estrarre una valida rubrica.
Testata, Righe ci avevo pensato anch'io ma poi mi sono chiesto se non sia troppo specifica degli ordini e quindi che invece di agevolare la comprensione del rapporto molti a molti non finisca invece per ostacolarla, ma ti ringrazio di averla citata perché comunque sia devo farlo anche io, due spiegazioni sono meglio di una.
Nella tabella ordini mi aggiungi il numero di ordine ma non si usa dare all'ordine il suo numero come chiave primaria? Per quale motivo due numeri?
Sempre nella Ordini metti il totale e pure in Righe Ordini, ma questo non è un errore da matita rossa? Per quanto ne so io nessun campo calcolato va inserito in tabella. Così almeno mi avevano insegnato.
Non comprendo a cosa serva hai le quantità, i prezzi e gli sconti non è un'inutile ridondanza?
In Righe Ordini metti riga omaggio perché, non basta sconto 100% al limite sconto omaggio?
UM l'avevo prevista all'interno della descrizione (es. centimetro. tubo rame diam. 10) ma hai fatto bene a ricordarla va messa, che tu sappia è obbligatoria per legge, o potrebbe anche bastare la citazione in descrizione?
Vedo che fai distinzione fra Articoli e Listino Articoli io qui intendevo usarlo nella seconda accezione.
Hai ragione comunque il prezzo articoli è troppo semplificato non va bene, ma penso che occorra ci sia la colonna del prezzo di costo alla produzione e la colonna ricarico ma niente campi calcolati.
Anche in Articoli mi aggiungi codice articoli se ho capito bene qui lo fai per via dei codici uguali dei fornitori.
Tieni conto che io ho ipotizzato un piccolo produttore di articoli per idraulica pertanto non ha problemi di inserire codici altrui i codici sono i suoi.
Nel libro avrei intenzione di suggerire qualche trucco per favorire i propri utenti nell'importazione dei dati da altri database e/o fogli di calcolo.
Di solito, o meglio ai miei tempi i fornitori inviavano i listini su fogli di calcolo (Excel), per importare senza problemi i codici senza incorrere nel problema che hai indicato, anteponevo tre lettere iniziali più un trattino (per favorirne la lettura) al codice dei fornitori, queste tre lettere erano nella tabella fornitori subito dopo la ragione sociale, le devi aggiungere sempre anche agli eventuali prodotti fatti dall'utente tre lettere e trattino altrimenti non funziona.
È semplice e a mio parere lavora bene. Le lettere sono estrapolate dalle ragioni sociali.
Tu che sistema usi, dei due codici, che vantaggi porta?
Sono d'accordo dire nome articolo suona ridicolo, ma se stai studiando da zero cosa è un database forse distrae meno, suona più facile insieme a nome cliente (ragione sociale), sarò scemo ma a me queste semplificazioni mi hanno sempre aiutato nello studio delle cose difficili.
Alla fine del capitolo su database e SQL era mia intenzione correggere tutte le semplificazioni usate, sempre ch'io mi ricordi che lo devo fare.
Carissimo tornu se non sei morto sotto il peso di questo mattone, sei indistruttibile.
Spero vorrai continuare a supportarmi. È la prima volta che confronto quello che credo di sapere sui database con uno esperto, te ne sono grato.
