Ciao Gianluigi, che ne pensi di ritornare alla progettazione classica del database, lasciando stare le tabelle ereditate?

Ciao Gianluigi, purtroppo adesso sono sommerso di lavoro e non ho tempo di verificare quanto hai postato.
Spero nel fine settimana di trovare uno spazietto per dargli un'occhiata.

Ciao Gianluigi,
se ho capito bene, hai postato un esempio di come vorresti gestire sul db la tabella relativa alle offerte, in particolare nell'ultima pagina dove proponi i possibili campi?

Allego il tuo file dove ho apportato alcune modifiche e aggiunte (ultima pagina) secondo la mia idea di come andrebbe impostata la tabella.
Se ho frainteso il tuo precedente post, mi spiegherai meglio cosa intendevi.
Ciao.

Ciao Gianlugi, per il discorso della nomenclatura, per me va bene quanto proposto da te, anche se io solitamente scrivo tutto in maiuscolo.

Ciao, sono in dubbio sul mettere il prefisso della tabella prima del nome del campo.
Se lo stesso campo, presente su due tabelle diverse, ha una chiave esterna, la chiave esterna come la imposti?
E poi, vuoi veramente usare le chiavi esterne? Perché non affidare al programma il controllo sull'immissione dei dati, tanto l'utente finale non credo che effettuerà mai dei lavori direttamente in sql sul db, ma lavorera solo tramite il gestionale.

Ritornando al discorso delle sequenze, valuta l'idea di utilizzare delle tabelle dove scrivere l'ultimo numero utilizzato, magari abinandolo all'anno.
Sul gestionale su cui lavoro, molti progressivi (fatture, bolle, registri iva, ecc.), sono insertiti in tabelle dove trovi il campo anno, il codice protocollo, e l'ultimo numero utilizzato.

Citazione da: Berserker79 - 08 Novembre 2015, 14:48:23

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.

Ciao Berserker79

Allora se capisco bene, visto che comunque per vari motivi occorre mantenere (almeno in parte) i listini storici che possono essere ripescati in base alla data (periodo da a) a questo punto diventa superfluo in RigheOrdini (intendo la tabella di collegamento fra ordini e articoli, OrdArt nel mio esempio) inserire il prezzo dell'articolo venduto, lo si potrebbe ripescare con una view o una query oppure sarebbe troppo complicato? O non è così che si fa normalmente?
Mantenete lo storico solo dei prezzi o anche quello delle descrizioni o/e specifiche? Se non lo mantenete come fate nei periodi di transizione?
Forse la cosa più giusta sarebbe quella di mantenere l'intero listino descrizioni comprese e poi darsi una regola di business che non so dopo 50 anni si rimuovono dal database. Ammesso che fra 50 anni ci siano ancora i computer. 
 

Ciao, nella tabella degli ordini metti anche il prezzo in modo da avere accesso immediatamente all'informazione evitando join fra le tabelle dei listini.

Lo storico va tenuto per il prezzo e non per le descrizioni. Nel caso del cambio di una specifica, non la si aggiorna, ma si crea una nuova posizione lasciando inalterata la vecchia.

Noi gestiamo tre tipi di listino su tre tabelle differenti, listini di acquisto, listini di cessione e listini di vendita al pubblico.
I listini di cessione/pubblico sono composti da tre campi che permettono di classificare il listino come listino standard, oppure offerta, oppure netto ecc.
Il sistema così composto, ci permette di tenere attivi più listini da poter utilizzare per le varie fasce di clienti.

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_TABELLA
TBEAN                       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.

Ho risolto installando dai sorgenti.