Vuoi dire che una grande tabella fa da base a delle viste di supporto, intendi questo quando parli di tabelle minori?
Si tratta di una tabella che nella prima colonna ha inserito il codice/nome della tabella minore, mentre nel secondo campo sono inseriti tutti i dati degli altri campi della tabella minore.
Faccio un esempio:
la tabella minore TBEAN, gestisce il tipo ean, al suo interno troviamo le colonne "TIPO EAN", "CODICE EAN", "EAN ABILITATO".
Nella tabella reale troveremo i dati in questo modo
CODICE_TABELLA DATI_TABELLATBEAN E1234567890123S
il dato presente nella colonna "DATI_TABELLA" contiene il carattere E che va associato alla colonna "TIPO EAN", i caratteri 1234567890123 da associare alla colonna "CODICE EAN"
e il carattere S che va associato alla colonna "EAN ABILITATO".
La mia tabellina ordini era solo per provare, l'ho estrapolata da un piccolo esempio che avevo tirato giù per parlare di Pragma in SQLite con Picavbg non ha nessuna pretesa di rappresentare una vera tabella, mi incuriosisce molto il fatto che, se capisco bene, nella tua azienda avete lo stesso listino con prezzi diversi distinti solo dalle date differenti. Ho capito bene? Ma se così fosse non c'è rischio di errori? Questo non si scontra con l'univocità nelle relazioni? Pensandoci bene forse è indispensabile un periodo di transazione fra i listini che permetta di smaltire il vecchio sul fronte della contabilità prima di entrare a regime. È per questo motivo che ci sono listini uguali con date e prezzi diversi? Immagino quindi che la chiave primaria preveda incorporata la data oppure la chiave è composita?
la tabella dei listini, ha due colonne che servono a stabilire i periodi di applicazione del listino, inizo periodo e fine periodo.
Questi due campi ti permettono di avere uno storico del listino, mentre se io aggiornassi il prezzo sempre sullo stesso record non potrei fare dei controlli a ritroso sulle variazioni del prezzo.
Ad adempio, oggi ordino al fornitore x, l'articolo y al prezzo z. Successivamnete il fornitore mi comunica un cambio prezzo, che vado a sovrascrivere al prezzo precedente.
Al momento della consegna dalla merce che avevo ordinato, come faccio a verificare se il prezzo che mi ha applicato è quello corretto alla data del mio ordine, tenendo anche conto che la fattura può arrivare anche diverso tempo dopo la data del mio ordine?
Per quanto riguarda la gestione della tabella, ovviamente le date fanno parte della chiave primaria, in modo che il listino non possa avere a partire dalla stessa data due prezzi differenti.
Pensavo che con i moderni computer un'attività “notturna” potesse essere evitata e si potesse controllare immediatamente. Se questo lo si potesse evitare io lo auspicherei, se il futuro è la vendita elettronica c'è bisogno di risposte immediate. Anche qui però pensandoci bene si può fare un primo controllo per la risposta immediata ( tipo lo abbiamo o no a magazzino), quindi il controllo più approfondito che coinvolga tutte le componenti interessate in fase successiva (tipo il controllo sulla carta di credito o solvibilità).
Quindi diciamo che ci sono tabelle che chiamo di "lavoro" che subiscono modifiche continumente, da parte degli utenti che svolgono le loro mansioni, mentre ci sono tabelle che chiamo "di consolidamento" che vengono gestite esclusivamente dalle routine notturne, e che contengolo solo dati validi.
Facciamo un esempio:
Faccio un ordine al fornitore di 30 articoli. Questo ordine si trova nella tabella di lavoro A e fino a quando non arriverà la consegna, non passerà sulla tabella di consolidamento B.
Al momento della consegna, rispetto al mio ordine originale, il fornitore non ha consegnato n articoli e di alcuni, ha consegnato delle quantità inferiori alla mia richiesta.
Sulla tabella di lavoro A avrò articoli ordinati, quantità ordinata, quantità ricevuta, mentre sulla tabella di consolidamento B, passeranno solo i movimenti validi perdendo di conseguenza gli articoli che il fornitore non mi ha consegnato. Perderò anche il campo della quantità ordinata, trovando solo la quantità ricevuta insieme ad altri dati come il numero fattura del fornitore.
Se devo realizzare per l'ufficio commerciale un report che mostri tutti gli ordini in consegna futura, ovviamente attingero dalla tabella A.
Mentre se devo realizzare un report che mostri l'analisi delle merci ricevute, attingo alla tabella B che risultà più indicata rispetto alla tabella A (che contiene anche lei i dati della merce ricevuta) in quanto è assente dalle righe superflue della merce non consegnata.
Se devo realizzare un report che mi indica il livello di servizio del fornitore, dovro necessariamente attingere alla tabella A in quanto è l'unica ad avere il dato di orinato e di consegnato.
Se devo realizzare un report sugli ordini consegnati in attesa di ricezione della fattura, dovrò puntare necessariamente alla tabella B che contiene questo dato.
Spero di aver spiegato bene la differenza fra le due tipologie di tabelle, come puoi vedere non è legato ad un discorso di risposta immediata alle richieste utente.
Ho momentaneamente sospeso la compilazione dei protocolli di lavoro anche perché essendo io quello che ne sa di meno sui gestionali, devo prima chiedere a voi.
Appena capisco un po di più di PostgreSQL ho intenzione di rimettermi al lavoro.
Riguardo la nomenclatura se proponessi ad esempio:
1. I nomi delle tabelle devono sempre essere plurali se un nome di tabella deve riportare un nome composto tipo AliquoteIva lo si rovescerà per ottenere un chiaro finale plurale e cioè IvaAliquote.
2. I nomi di campo devono sempre essere singolari si potranno abbreviare la dove non è possibile fraintenderne il significato.
3. I nomi di campo saranno preceduti dalle prime tre lettere del nome della tabella più il tratto di sottolineatura fatto salvo il punto 2 e cioè fraintendere a quale tabella ci si riferisce.
4. Le chiavi primarie inizieranno sempre con ID_ e le prime tre lettere del nome della tabella fatto salvo il punto 2.
5. Le chiavi esterne saranno nominate come le loro chiavi di origine.
Se ho capito quanto dici questo non andrebbe bene?
Per quanto riguarda i nomi delle tabelle io utilizzerei solo caratteri maiuscoli, non so perchè ma quando programmo in sql mi piace utilizzare solo maiscuolo
.
Per quanto riguarda i campi chiave, io sposterei alla fine _ID.
Purtroppo di postgresql non conosco nulla, volevo utilizzarlo ma ho fatto un passo indietro perchè non sono riuscito e non so se sia possibile, collegargli un database esterno (nel mio caso il db del gestionale). Anzi se quancuno di voi sa se è possibile collegare un db esterno allo stesso modo dei linked server su sql server sarebbe bellissimo.
Ciao.
