Ciao Gianluigi,:D
fammi capire, vuoi esempi di documenti per poter capire quali sono le informazioni utili alla progettazione del DB ?
Diciamo che se questa è la tua richiesta , è vero che potremmo prendere spunto ma non sarà sufficente in quanto
nel DB ci saranno tanti campi che sui documenti naturalmente non ci sono, comunque dovrei avere del materiale da
proporti. La strada che hai indicato per lo sviluppo del progetto diciamo che và bene, è ovvio che potrà essere modificata
strada facendo. Ci chiedi di non lamentarci se pretenderai il corretto svolgimento...ma secondo te ?... :P
Ciao Gianluigi, non intendevo muovere critiche al tuo operato, semplicemente volevo riporre l'attenzione sul fatto che la progettazione del DB va svolta a 360 gradi.Carissimo sotema, lo so a volte ho modi bruschi, non volevo apparire scortese, e tu sei autorizzato a criticarmi quanto ti pare e piace permesso esteso a tutti quelli che lo vogliono fare, anche se tu e tornu avete una licenza con poteri di critica extra. :D
Sicuramente ho frainteso cosa intendevi per documenti, ho pensato che ti riferissi ai soli documenti fiscali (fatture, ddt, ricevute fiscali...):ok:
ora è chiaro che ti riferivi a tutto ciò che costituisce un'azienda.
Bene la standardizzazione dei termini e della struttura del DB uno dei principi basilari per produrre una base dati solida.
Allego la mini guida sull'installazione di Postgresql. Sper di avere raggiunto il risultato di fornire le informazioni di base senza creare confusione nel lettore. Per ogni dubbio o richiesta sono disponibile.
Temo che nei comandi inseriti nella guida ci sia un refuso ti si è spostato il simbolo di User ($) dopo main e questo in un primo momento mi ha confuso in quanto avendomi Ubuntu installato la 9.3 credevo che il malfunzionamento dipendesse da quello.Probabilmente il simbolo $ cui ti riferisci è il carattere terminale del prompt utente
Non avendo capito ho provato a cambiare peer con trust in gedit (sudo gedit /etc...) ma ho ottenuto un errore al momento del salvataggio.
Purtroppo adesso devo andare ho un impegno inderogabile sta per iniziare Dawnton Abbey :P
Ci aggiorniamo a mezzanotte :ciao:
Probabilmente il simbolo $ cui ti riferisci è il carattere terminale del prompt utente
Quale errore ottieni al salvataggio?
Temo che nei comandi inseriti nella guida ci sia un refuso ti si è spostato il simbolo di User ($) dopo main e questo in un primo momento mi ha confuso in quanto avendomi Ubuntu installato la 9.3 credevo che il malfunzionamento dipendesse da quello.quale è stata la tua reazione, ti è scappata una risata oppure sei rimasto male vedendo svilito il tuo impegno? Probabilmente un insieme misto ad altro a cui non desidero pensare.
Non avendo capito ho provato a cambiare peer con trust in gedit (sudo gedit /etc...) ma ho ottenuto un errore al momento del salvataggio.
Tranquillo Gianluigi,Speriamo non sappia che partecipi a questo forum :rotfl:
ho sopportato di peggio, molto peggio. Ho la FORTUNA ( :o) di vivere nello stesso palazzo di mia suocera. Credo non serva aggiungere altro...
Qualunque dubbio, perplessità o chiarimento non esitare a chiedere.Grazie
:ciao:
gian@gian:~$ psql -U giangi -d template1
Password for user giangi:
psql (9.3.10)
Type "help" for help.
template1=> \l
template1=> \du
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------+-----------
giangi | Create role, Create DB | {}
postgres | Superuser, Create role, Create DB, Replication | {}
template1=> \c rubinettofelice
You are now connected to database "rubinettofelice" as user "giangi".
rubinettofelice=> \d
List of relations
Schema | Name | Type | Owner
--------+----------+-------+--------
public | articoli | table | giangi
public | artord | table | giangi
public | clienti | table | giangi
public | ordini | table | giangi
(4 rows)
rubinettofelice=> \dn
List of schemas
Name | Owner
--------+----------
public | postgres
(1 row)
rubinettofelice=> \d+ clienti
Table "public.clienti"
Column | Type | Modifiers | Storage | Stats target | Description
-------------+-----------------------+-----------+----------+--------------+-------------
id_cli | integer | not null | plain | |
cli_nome | character varying(15) | | extended | |
cli_cognome | character varying(15) | | extended | |
cli_citta | character varying(20) | | extended | |
Indexes:
"clienti_pkey" PRIMARY KEY, btree (id_cli)
Referenced by:
TABLE "ordini" CONSTRAINT "ordini_id_cli_fkey" FOREIGN KEY (id_cli) REFERENCES clienti(id_cli)
Has OIDs: no
rubinettofelice=> \d+ articoli
Table "public.articoli"
Column | Type | Modifiers | Storage | Stats target | Description
------------+-----------------------+-----------+----------+--------------+-------------
id_art | integer | not null | plain | |
art_nome | character varying(25) | | extended | |
art_prezzo | real | | plain | |
Indexes:
"articoli_pkey" PRIMARY KEY, btree (id_art)
Referenced by:
TABLE "artord" CONSTRAINT "artord_id_art_fkey" FOREIGN KEY (id_art) REFERENCES articoli(id_art)
Has OIDs: no
rubinettofelice=> \d+ artord
Table "public.artord"
Column | Type | Modifiers | Storage | Stats target | Description
-----------------+---------+-----------+---------+--------------+-------------
id_art | integer | not null | plain | |
id_ord | integer | not null | plain | |
artord_quantita | integer | | plain | |
artord_prezzo | real | | plain | |
Indexes:
"artord_pkey" PRIMARY KEY, btree (id_art, id_ord)
Foreign-key constraints:
"artord_id_art_fkey" FOREIGN KEY (id_art) REFERENCES articoli(id_art)
"artord_id_ord_fkey" FOREIGN KEY (id_ord) REFERENCES ordini(id_ord)
Has OIDs: no
rubinettofelice=> \d+ ordini
Table "public.ordini"
Column | Type | Modifiers | Storage | Stats target | Description
------------+---------+-----------+----------+--------------+-------------
id_ord | integer | not null | plain | |
id_cli | integer | | plain | |
ord_data | text | | extended | |
ord_sconto | integer | | plain | |
Indexes:
"ordini_pkey" PRIMARY KEY, btree (id_ord)
Foreign-key constraints:
"ordini_id_cli_fkey" FOREIGN KEY (id_cli) REFERENCES clienti(id_cli)
Referenced by:
TABLE "artord" CONSTRAINT "artord_id_ord_fkey" FOREIGN KEY (id_ord) REFERENCES ordini(id_ord)
Has OIDs: no
rubinettofelice=> SELECT id_Cli, cli_nome, cli_cognome, cli_citta FROM clienti;
rubinettofelice
id_cli | cli_nome | cli_cognome | cli_citta
--------+------------+-------------+-------------------
1 | Pippo | Franco | Roma
2 | Giobatta | Parodi | Genova
3 | Franco | Neri | Firenze
4 | Franca | Piombo | Milano
5 | Daniele | Persicotti | Bergamo
6 | Dino | Ciabatta | Trieste
7 | Adele | Riposi | Venezia
8 | Fraz | Genvesi | Bolzano
9 | Concetto | Lopresti | Palermo
10 | Efisio | Mannu | Cagliari
11 | Franco | Gullo | Reggio Calabria
12 | Daria | Ricotto | Bologna
13 | Aldo | Magro | L'Aquila
14 | Gino | Viottolo | Città di Castello
15 | Pina | Lolli | Roma
16 | Giovanna | Serra | Roma
17 | Franca | Stella | Roma
18 | Gian Carlo | Zerbi | Genova
19 | Tony | Birulò | Trieste
20 | Aldo | Birulò | Venezia
21 | Mario | Parodi | Genova
(21 rows)
rubinettofelice=> SELECT id_art, art_nome, art_prezzo FROM articoli;
rubinettofelice
id_art | art_nome | art_prezzo
--------+--------------------------+------------
1001 | Rubinetto piccolo | 10
1002 | Rubinetto medio | 15
1003 | Rubinetto grande | 20
1004 | Tubo rame diam. 1 | 0.055
1005 | Tubo rame diam. 2 | 0.11
1006 | Chiave pappagallo media | 8
1007 | Chiave pappagallo grande | 15
1008 | Giratubi medio | 12
1009 | Giratubi grande | 30.5
10010 | Treccia stoppa | 5
10011 | Pasta siliconata | 8.7
10012 | Pasta lavamani grande | 6
10013 | Busta O-Ring assortiti | 3.5
10014 | Serie 12 cacciaviti T | 12
10015 | Serie 12 cacciaviti X | 12
10016 | Cassetta A idraulico | 20
10017 | Cassetta B idraulico | 112
10018 | Rotolo stagno saldatura | 7
10019 | spazzola acciaio | 5
10020 | tagliatubi univerale | 23.5
(20 rows)
Oggi qualche passetto avanti nella comprensione dei database penso di averlo fatto. :DBene.
Una cosa che non ho capito \dn a me mostra solo public e postgres come schema.Devo pensare lo Schema come un contenitore in cui puoi creare oggetti del db da tenere separati da altri consentendone l'accesso a gruppi di utenti specifici. E' perfettamente lecito avere una tabella Cliente nello schema Public ed una tabella Cliente nello schema Gianluigi.
CREATE SCHEMA nomeschema ...Ciao Sotema,http://docs.itpug.org/ (http://docs.itpug.org/)
quindi non real ma numeric per precisione decimale sui soldi, grazie. :ok:
Avevo un po guardato saltabeccando la sontuosa documentazione di PostgreSQL, peccato che sia in inglese che d'accordo che è un pochino più semplice di prima da capire visto il grande aiuto di Google Translator, però quando si affrontano concetti nuovi... :rolleyes:
Ti chiedo alcune cose, ma sia chiaro che è senza impegno alcuno, intendo dire che se non hai tempo o voglia non mi rispondi e io rimango contento di te in uguale misura, lo giuro davvero.se ti riferisci ai vari database la loro locazione è determinata dalla variabile d'ambiente PGDATA, può variare a seconda del SysOp in uso (Linux, Win, BSD...), su linux può variare a seconda della distribuzione , in genere sono nella cartella /var/lib/postgresql/9.4/main/base ma sono identificati da un codice numerico e non è immediato associare un cluster, questo è il termine esatto, al nome del DB.
Già hai spiegato che PostgreSQL può lavorare sia in locale che in rete e la tua guida mi ha permesso di creare un database di prova ecc..., potresti ora delineare un po meglio il quadro:
Dove sono i vari file di PostgreSQL?
Come lo/li spedisci a un cliente?Tra le varie utilità a disposizione vi è l'applicazione pg_dump che esegue il backup di un intero database; dispone di molte opzioni (a te la ghiotta occasione di studiarle). Per effettuare la copia della struttura di un DB vuoto da trasferire al cliente puoi usare la sintassi:
pg_dump -f rubifelix -U test -s -C -d rubinettofeliceCrei il database da codice al momento del primo avvio? Se si o a volte, dove lo inserisci?In linea di principio preferisco creare una classe specializzata per creare il db, nel caso questi non esista, al primo avvio del programma.
Ciao a tutti, progetto interessante a cui mi piacerebbe dare un contributo.Grande Berserker79,
Inizio col descrivere brevemente la struttura del gestionale, basato su DB2, che utilizzo in azienda.
Prendo in esempio la tabella anagrafica dell'articolo:Vuoi dire che una grande tabella fa da base a delle viste di supporto, intendi questo quando parli di tabelle minori?
La tabella riporta tutti gli attributi legati all'articolo come codice, descrizione, peso, unità di misura, codice merceologico ecc..
a sua volta un attributo dell'articolo, può avere una propria tabella, ad esempio l'unità di misura viene gestita dalla sua tabella dalla quale possiomo selezionarne il tipo desiderato.
La tabella articolo credo abbia un legame con oltre 50 tabelle "minori", fra le quali scegliere i vari attributi.
Le tabelle "minori", in realtà non sono gestite in maniera individuale, ma fanno parte di un'unica tabella.
Questa ha una colonna che funge da identificativo per tutte le tabelle "minori" mentre le altre colonne riportano i dati veri e propri.
Faccio un paragone con la tabella articolo creata da Gianlugi,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?
dove abbiamo id_art, art_nome, art_prezzo mentre da me il prezzo, che varia periodicamente, ha una sua tabella dedicata in cui trovo il codice articolo, le date di validità e il prezzo.
Oltre alle tabelle anagrafiche, ci sono le tabelle su cui vengono inseriti giornalmente i dati provenienti da le varie mansioni degli uffici,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à).
ad esempio l'entrata merce al magazzino, la spedizione della merce ai clienti, gli ordini in arrivo dai fornitori, le registrazioni contabili ecc.
Tutte queste attività, sono gestite da molteplici tabelle dedicate, ad esempio tutte le attività di uscita merce giornaliere, vengono memorizzate su una prima tabella, successivamnete in notturna, delle routine analizzano tutti i dati e quelli che superano tutta una serie di controlli, vengono memorizzati in una seconda tabella che quindi conterrà solo i movimenti corretti, arrichhendoli di ulteriori informazioni.
Il campi delle tabelle hanno una nomenclatura che segue questa logica, i primi due caretteri riportano i primi due caretteri della tabella di appartenenza, i restanti, identificano il campo vero e proprio, in questo modo il campo XXART sappiamo che appartiene alla tabella dell'anagrafica articolo, mentre il campo YYART appartiene alla tabella delle uscite merci.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.
Questo torna utile in fase di progettazione perchè permette di poter idenficare meglio le tabelle e perchè al netto del prefisso, il campo ha lo stesso nome in tutto il db.
A disposizione per qualsiasi chiarimento, ciao.
...
Ora vado a farmi delle caldarroste... :ciao:
Vuoi dire che una grande tabella fa da base a delle viste di supporto, intendi questo quando parli di tabelle minori?
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.
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à).
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?
...
(un sacco di notizie :D )
...
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.
Ciao Berserker79,
ti ringrazio molto per le tue dettagliate spiegazioni :ok:, certo è che più mi parlate di gestionale e più mi rendo conto in che bel ginepraio vi sto attirando :DCaro Sotema,Mai successo.
ho scoperto una cosa che mi ha lasciato di stucco: Nella mia home c'è un file (.pgpass) che mostra in chiaro la password dell'utente giangi ma non l'avevamo criptata in md5? :rolleyes:È forse dovuto al fatto che per brevità l'ho inserita direttamente nel codice?
:ciao: :ciao:
dovrei vedere il codice...
Bravo Gianluigi, vedo che ti stai impegnando. ;DL'impegno ce lo metto, purtroppo il cervello è quello che è :mad:
Mai successo.
dovrei vedere il codice...
Public $Conn As New Connection
Public sNomeDB As String = "rubinettofelice"
Public Sub AproDB()
With $Conn
.Close()
.Type = "postgresql"
.Host = "localhost"
.Login = "giangi"
.Password = "CippaLippa"
.Name = sNomeDB
.Open()
End With
Catch
Print Error.Text
End
Public Sub ChiudoDB()
$Conn.Close
Catch
Print "Incredibile errore su Close"
EndHai ragione, il file .pgpass viene creato da pgadmin3 se decidi di salvare la password. la cosa mi era sfuggita perchè non utilizzo mai questa funzione.Bravo Gianluigi, vedo che ti stai impegnando. ;DL'impegno ce lo metto, purtroppo il cervello è quello che è :mad:CitazioneMai successo.
dovrei vedere il codice...
Ho creato l'utente come da tue istruzioni salvo cambiare test in giangi e la password.
(Mi è venuta in mente una cosa la prima volta che ho usato pgAdminIII ho salvato la password ma poi mi sono accorto che quando accedevo al database da terminale con psql -U giangi -d template1 non mi veniva più chiesta la password e allora sono andato di nuovo su pgAdminIII e ho tolto la spunta e adesso è tornato a chiederla. Che sia dovuto a questo?)
:ciao:
...
Hai ragione, il file .pgpass viene creato da pgadmin3 se decidi di salvare la password. la cosa mi era sfuggita perchè non utilizzo mai questa funzione.
Ciao Berserker79,
ho trovato (http://blog.2ndquadrant.it/postgresql-9-5-import-foreign-schema/) dove avevo letto la notizia, spero ti sia utile.
:ciao:
Sai mi sto rendendo conto di che bestia è PostgresSQL rispetto ai giocattoli da me usati fino ad ora ho dato il comando template1=> \h ALTER e... mi sono spaventato del risultato.
Veramente straordinario quello che può fare questo database, più ne leggo e più mi accorgo di quel niente che so e pensare che ho solo iniziato e che una buona parte di quello che ho letto non l'ho neanche capita... :rolleyes:
È interessantissimo e continuo a “picchiarmi” con lui il divertimento, almeno il mio, prosegue... :D
:ciao:
Hai dato un'occhiata al link che ti ho segnalato? Contienela documentazione, versione 9.1, quasi completamente tradotta in italiano.
:ok:
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.
CREATE TABLE mioschema.impiegati(
ID_Imp serial,
imp_codice text,
imp_cognome text,
imp_nome text,
PRIMARY KEY(ID_Imp),
UNIQUE(imp_codice)
);
– vari inserimenti con lo stesso schema devo ancora capire le funzioni di PostgreSQL.
INSERT INTO mioschema.impiegati (imp_codice, imp_cognome, imp_nome) VALUES ('codice6', 'Sergia', 'Mellina');
SELECT nextval('mioschema.impiegati_id_imp_seq');
INSERT INTO mioschema.impiegati (ID_Imp, imp_codice, imp_cognome, imp_nome) VALUES (nextval('mioschema.impiegati_id_imp_seq'), 'codice8', 'Lucia', 'Mondello');
INSERT INTO mioschema.impiegati VALUES (nextval('mioschema.impiegati_id_imp_seq'), 'codice9', 'Lorenzo', 'Tramaglino');CREATE SEQUENCE mioschema.pippo
START WITH 1
INCREMENT BY 1
MINVALUE 1
MAXVALUE 3
CYCLE;
CREATE TABLE mioschema.fornitori(
ID_for mioschema.pippo,
for_cognome text,
for_nome text,
PRIMARY KEY(ID_for)
);
===============================================================================================
INSERT INTO mioschema.fornitori VALUES (nextval('mioschema.pippo'), 'Ciccia', 'Pino');
ERROR: column "id_for" is of type mioschema.pippo but expression is of type bigint
LINE 1: INSERT INTO mioschema.fornitori VALUES (nextval('mioschema.p...
^
HINT: You will need to rewrite or cast the expression.
================================================================================================
INSERT INTO mioschema.fornitori (ID_for, for_cognome, for_nome) VALUES (1, 'Bella', 'Lella');
ERROR: column "id_for" is of type mioschema.pippo but expression is of type integer
LINE 1: ...fornitori (ID_for, for_cognome, for_nome) VALUES (1, 'Bella'...
^
HINT: You will need to rewrite or cast the expression.
==================================================================================================
INSERT INTO mioschema.fornitori (ID_for, for_cognome, for_nome) VALUES (nextval('mioschema.pippo'), 'Bella', 'Lella');
ERROR: column "id_for" is of type mioschema.pippo but expression is of type bigint
LINE 1: ...fornitori (ID_for, for_cognome, for_nome) VALUES (nextval('m...
^
HINT: You will need to rewrite or cast the expression.
=====================================================================================================
INSERT INTO mioschema.fornitori (for_cognome, for_nome) VALUES ('Bella', 'Lella');
ERROR: null value in column "id_for" violates not-null constraint
DETAIL: Failing row contains (null, Bella, Lella).
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. ;D
:ciao:
:ok: me lo aveva detto anche Tornu, Sotema lo aveva confermato, mi arrendo :D
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.Puoi farmi un esempio, non mi è molto chiaro cosa fai, attivi un campo obsoleto?
Noi gestiamo tre tipi di listino su tre tabelle differenti, listini di acquisto, listini di cessione e listini di vendita al pubblico.:ok:
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.
Codice: [Seleziona]CREATE TABLE mioschema.impiegati(
ID_Imp serial,
imp_codice text,
imp_cognome text,
imp_nome text,
PRIMARY KEY(ID_Imp),
UNIQUE(imp_codice)
);
– vari inserimenti con lo stesso schema devo ancora capire le funzioni di PostgreSQL.
INSERT INTO mioschema.impiegati (imp_codice, imp_cognome, imp_nome) VALUES ('codice6', 'Sergia', 'Mellina');
SELECT nextval('mioschema.impiegati_id_imp_seq');
INSERT INTO mioschema.impiegati (ID_Imp, imp_codice, imp_cognome, imp_nome) VALUES (nextval('mioschema.impiegati_id_imp_seq'), 'codice8', 'Lucia', 'Mondello');
INSERT INTO mioschema.impiegati VALUES (nextval('mioschema.impiegati_id_imp_seq'), 'codice9', 'Lorenzo', 'Tramaglino');
NOTA2: Avendo letto con SELECT il nextval mi si è creato un vuoto.
CREATE TABLE fornitore
(
fornitore_id serial,
...
);CREATE SEQUENCE fornitore_id_seq
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807
START 1
CACHE 1;
CREATE TABLE fornitore
(
fornitore_id integer DEFAULT nextval('fornitore_id_seq'::regclass),
...
)CREATE SEQUENCE fornitore_id_seq
INCREMENT 2
MINVALUE 1
MAXVALUE 9223372036854775807
START 1
CACHE 1;CREATE SEQUENCE prova_id_seq
INCREMENT -1
MINVALUE 10
MAXVALUE 1000
START 1000
CACHE 1;NOTA2: Avendo letto con SELECT il nextval mi si è creato un vuoto.l'istruzione SELECT nextval('nome_sequenza'::regclass) non fa altro che forzare l'incremento della sequenza, non avendo inserito record nella tabella cui questa si riferisce ottieni un 'vuoto'. Esistono alcuni metodi per manipolare le sequenze.
DOMANDA: Ho visto che ci sono parecchie funzioni in PostgreSQL immagino che siano più veloci di quanto può fare Gambas ciclando la SQL, come ti regoli di solito?
Ho visto che per usare COPY, ad esempio molto potente per copiare i dati da un file di testo, occorre avere i privilegi di super user; è possibile cambiare ruolo durante l'utilizzo da parte dell'utente? Oppure c'è un modo per dare questo specifico privilegio ad un user?Ti riferisci al comando COPY di sql oppure al comando \copy di psql? Ad ogni modo, per utilizzare il comando COPY (FROM/TO) da sql devi possedere il privilegio di SELECT (per COPY TO) sulla tabella da cui vuoi prelevare i dati, il privilegio INSERT per la tabella in cui scrivere i dati (per COPY FROM). In realtà ti basta avere quei privilegi per le colonne che utilizzi nel comando.
ALTER ROLE nomeutente WITH SUPERUSER;gian@gian:~$ psql -U test -d template1
Password for user test:
psql (9.3.10)
Type "help" for help.
template1=> \c mio_test
You are now connected to database "mio_test" as user "test".
mio_test=> \d Articoli
Table "public.articoli"
Column | Type | Modifiers
-----------------+-----------------------+-----------
id_art | character varying(10) |
art_descrizione | text |
art_prezzo | numeric |
mio_test=> SELECT * FROM articoli;
mio_test=> COPY Articoli
mio_test-> FROM '/home/gian/Articoli.txt'
mio_test-> DELIMITER ';';
ERROR: must be superuser to COPY to or from a file
HINT: Anyone can COPY to stdout or from stdin. psql's \copy command also works for anyone.
mio_test=> \du
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------+-----------
giangi | Create role, Create DB | {}
postgres | Superuser, Create role, Create DB, Replication | {}
test | Create role, Create DB | {}
Ciao Sotema,Si solo un SUPERUSER può copiare da o verso un file. Un utente normale può usare COPY tabella (campo1,campo2,...) FROM stdin WITH DELIMITER 'carattere_separatore';
grande :ok: spiegazioni dettagliatissime ora mi metto a studiare :ok: :D
Riguardo a COPY a seguire quanto ho tentato di fare, come vedi il database impedisce all'utente di copiare da un file di testo dicendo che non ha i privilegi di superuser anche se poi suggerisce che chiunque può copiare. Nota che test è colui che ha creato il database e può usare select e insert :rolleyes:Codice: [Seleziona]Ma il comando di psql (\copy) può essere usato da Gambas con exec?gian@gian:~$ psql -U test -d template1
Password for user test:
psql (9.3.10)
Type "help" for help.
template1=> \c mio_test
You are now connected to database "mio_test" as user "test".
mio_test=> \d Articoli
Table "public.articoli"
Column | Type | Modifiers
-----------------+-----------------------+-----------
id_art | character varying(10) |
art_descrizione | text |
art_prezzo | numeric |
mio_test=> SELECT * FROM articoli;
mio_test=> COPY Articoli
mio_test-> FROM '/home/gian/Articoli.txt'
mio_test-> DELIMITER ';';
ERROR: must be superuser to COPY to or from a file
HINT: Anyone can COPY to stdout or from stdin. psql's \copy command also works for anyone.
mio_test=> \du
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------+-----------
giangi | Create role, Create DB | {}
postgres | Superuser, Create role, Create DB, Replication | {}
test | Create role, Create DB | {}
:ciao:
PS: mi scuso col Manzoni per aver confuso un suo personaggio con la spiaggia di Palermo :-[
CitazioneLo 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.Puoi farmi un esempio, non mi è molto chiaro cosa fai, attivi un campo obsoleto?
Scusate ragazzi ma sono due giorni (quasi tre) che mi picchio col sistema operativo (Ubuntu 14.04.3). :-[Sbagliando si impara... ;D
Ho fatto un errore che lo ha reso instabile e alla fine mi sono deciso a reinstallare lasciando però la partizione /home intatta. Il fatto è che prima di decidermi alla reinstallazione le ho provate tutte quelle che so ma anche che non so e infatti ho solo perso tempo.
Ora pare funzionare.
@Sotema,Il valore massimo di una sequenza è pari a 263-1 per le sequenze ascendenti e -1 per le sequenze discendenti; raggiunto tale valore la prossima chiamata a nextval() genera un errore. La soluzione è far ripartire la sequenza. Ovviamente devi gestire la cosa qualora il campo controllato dalla sequenza debba contenere valori unici.
seguendo i tuoi consigli finalmente sono riuscito a creare con SEQUENCE la chiave auto incrementale come desideravo per capire anche il ciclo.
É molto semplice, arrivato all'ultimo numero ricomincia da capo ma attualmente non riesco a immaginarmene un utilizzo pratico.
Lo studio di PostgreSQL continua... :D
io chiederei a sotema di darci una dritta in quanto è l'unico a usare già PostgreSQL che, se ho capito bene, cambia tutto in minuscolo.La 'traduzione' in minuscolo è una convenzione utilizzata per migliorare la lettura delle query, dove le parole chiave vengono scritte in maiuscolo per distinguerle dai nomi di campi, tabelle, funzioni ed ogni altro oggetto del DB. Esiste comunque la possibilità, che personalmente non utilizzo mai e che sconsiglio vivamente di memorizzare i nomi in maiuscolo, i doppi apici: CREATE TABLE "CLIENTE" ...
Sotema hai parlato anche di standardizzazione della struttura cosa intendevi esattamente?
Vi rimanderei al primo post quello di apertura di questa discussione, siamo d'accordo sul sentiero da seguire per non perderci o avete proposte più sensate e/o complete da avanzare?Ora vado a rileggerlo.
Grazie
:ciao:
La 'traduzione' in minuscolo è una convenzione utilizzata per migliorare la lettura delle query, dove le parole chiave vengono scritte in maiuscolo per distinguerle dai nomi di campi, tabelle, funzioni ed ogni altro oggetto del DB. Esiste comunque la possibilità, che personalmente non utilizzo mai e che sconsiglio vivamente di memorizzare i nomi in maiuscolo, i doppi apici: CREATE TABLE "CLIENTE" ...
Riguardo la standardizzazione dei nomi, ogni strada è valida, purché la si rispetti in tutte le tabelle; circa la struttura ti faccio un esempio pratico.
Nella tabella cliente abbiamo il campo cli_id che diventa relazione per la tabella ordine_cliente, ebbene il campo nella tabella ordine_cliente deve chiamarsi anch'esso cli_id.
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.
Ciao, sono in dubbio sul mettere il prefisso della tabella prima del nome del campo.Ciao Berserker79,
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.
Riguardo l'uso delle chiavi esterne vorrei precisare che il loro scopo principale è quello di garantire che non vengano immessi valori non congrui in un determinato campo; ad esempio nella tabella ordini il valore di cliente_id deve obbligatoriamente esistere nella tabella clienti. in caso contrario PostgreSQL impedirà l'immissione del record. Ma se l'immissione dati viene effettuata tramite un applicativo (non da sql) tale verifica la puoi fare molto semplicemente popolando una combobox con tutti i clienti attivi, rendendo inutile la FK. In alternativa dovresti gestire l'eventuale messaggio di errore, cosa assai più complicata.
1. I nomi delle tabelle devono sempre essere plurali se un nome di tabella deve riportare un nome composto tipo aliquote_iva lo si rovescerà per ottenere un chiaro finale plurale e cioè iva_aliquote.Premesso che non ho remore ad applicare la metodologia indicata queste le mie considerazioni.
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.
Si potrebbe aggiungere che se una tabella è composita il prefisso raddoppierà tipo rig_ord_prezzo.
4. Le chiavi primarie inizieranno con le prime tre lettere del nome della tabella fatto salvo il punto 2 e 3 e finiranno con _id.
5. Le chiavi esterne saranno nominate come le loro chiavi di origine.
6. Più in generale direi che che tutti i nomi escluso i comandi SQL vadano scritti minuscolo e separati dallo underscore o trattino basso.
7. Per facilitare la lettura delle QUERY proporrei di scriverle su più righe tipo (scusate la banalità):
sMioSql = "SELECT *"
sMioSql &= " FROM clienti"
sMioSql &= " ORDER BY cli_cognome DESC,"
sMioSql &= " cli_nome DESC"
sMioSql &= ";"
SELECT prodotti.descrizione, fornitori.ragionesociale FROM prodotti, frornitori ...;SELECT p.descrizione, f.ragionesociale FROM prodotti as p, fornitori as f ...;
Premesso che non ho remore ad applicare la metodologia indicata queste le mie considerazioni.
1. OK
2. OK
3. Di solito non uso prefissi nel nome di campo, preferisco usare gli alias1
4. Non mi piace usare il trattino basso, rallenta la digitazione, solitamente uso idcliente e non id_cliente.
5. Assolutamente d'accordo
6. Vedi punto 3
7. Se vuoi che la sentenza SQL nel codice sia comprensibile dovrai obbligatoriamente attenerti a questo.
1 Gli alias sono un modo per abbreviare la sentenza SQL. Ad esempio invece di scrivereCodice: [Seleziona]puoi scrivere:SELECT prodotti.descrizione, fornitori.ragionesociale FROM prodotti, frornitori ...;Codice: [Seleziona]dove p ed f sono gli alias di tabella. In query molto lunghe sono molto utili, indispensabili quanto due o più nomi di campo nella query sono uguali.SELECT p.descrizione, f.ragionesociale FROM prodotti as p, fornitori as f ...;
Ciao Sotema,E fino a qui tutto normale...
scusa ma mi scappa da ridere non per quello che scrivi, ci mancherebbe! Ma per la situazione che si è venuta a creare, fino ad ora siamo in quattro che abbiamo detto la nostra sulla nomenclatura e cane se ce n'è uno che è d'accordo con gli altri. :rotfl:
Forse ma non sono sicuro Tornu potrebbe avvicinartisi però ama le abbreviazioni tipo piva al posto di partitaiva (o partita_iva).Almeno in questo caso siamo d'accordi in due, anch'io come Tornu preferisco abbreviare laddove possibile. Gli esempi che ho postato erano solo...esempi.
Berserker79 vorrebbe tutto maiuscolo PARTITA_IVA, io il CamelCase PartitaIva e se non ho capito male tu semplicemente partitaiva.
Be insomma altrimenti non saremmo italiani. :D
Ripeto se ho capito bene sei d'accordo su abbreviare i nomi solo dove non ci può essere incomprensione se ad esempio Tornu a cui piacciono le abbreviazioni "spinte" ha voglia e tempo può postare un elenco di abbreviazioni per evitarcele (le incomprensioni).Se e appena avrò tempo preparo un elenco di abbreviazioni anch'io, poi sceglieremo tra tutte le proposte.
La chiave primaria scritta idcliente a me va bene anche io non ho remore, solo sono molto paciugone e tendo sempre a confondermi è per quello che metto il prefisso per sapere di chi è il campo io quelle poche volte che ho creato query complicate ho sempre usato gli alias non sapevo che il prefisso me le potesse evitare :rolleyes:
Ricapitoliamo:
1. I nomi delle tabelle non contengono spazi e 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 non possono contenere spazi né lettere accentate es. citta e non città (è ovvio ma è bene dirlo).
3. Le chiavi primarie inizieranno con id tipo idcliente
4. Le chiavi esterne saranno nominate come le loro chiavi di origine.
5. Per facilitare la lettura delle QUERY le scriveremo su più righe tipo:
sMioSql = "SELECT *"
sMioSql &= " FROM clienti"
sMioSql &= " ORDER BY cognome DESC,"
sMioSql &= " nome DESC"
sMioSql &= ";"
Caro Berserker79 io e te ci dobbiamo sacrificare e probabilmente un po anche Tornu ma non possiamo proprio inimicarci Sotema che è l'unico che conosce PostgreSQL. ;D :P
Scherzi a parte visto che dobbiamo dialogare con lui tanto vale farlo come vuole PostgreSQL.
Ci abitueremo meglio a leggerne le risposte.
:ciao:
Forse ma non sono sicuro Tornu potrebbe avvicinartisi però ama le abbreviazioni tipo piva al posto di partitaiva (o partita_iva).Almeno in questo caso siamo d'accordi in due, anch'io come Tornu preferisco abbreviare laddove possibile. Gli esempi che ho postato erano solo...esempi.
Berserker79 vorrebbe tutto maiuscolo PARTITA_IVA, io il CamelCase PartitaIva e se non ho capito male tu semplicemente partitaiva.
Be insomma altrimenti non saremmo italiani. :D
Per quanto riguarda il tutto maiuscolo apprezzato da Berserker79, purtroppo come hai già scoperto è PostgrSQL stesso che pone dei vincoli e dover scrivere sempre i nome racchiusi tra doppi apici può portare ad errori, oltre che complicare la vita.
Anche io sono d'accorso sull'usare le abbrevazioni per tabelle e campi, usando lo stesso nome per un campo che si trova su più tabelle.
Ad esempio, l'ipotetica tabella "clienti" avra il campo "cliente_id" che sarà chiave primaria, mentre la tabella "ordini_clienti" avra sempre il campo "cliente_id" anche se qui non è parte della chiave primaria.
Mi raccomando attieniti all'ultima nomenclatura in cinque punti idcliente, id davanti non più dietro e senza underscore.
:ciao:
PS: Io comando... ma decide Sotema ;D
# DO NOT DISABLE!
# If you change this first entry you will need to make sure that the
# database superuser can access the database using some other method.
# Noninteractive access to all databases is required during automatic
# maintenance (custom daily cronjobs, replication, and similar tasks).
#
# Database administrative login by Unix domain socket
local all postgres md5
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all peer
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication postgres peer
#host replication postgres 127.0.0.1/32 md5
#host replication postgres ::1/128 md5
gian@gian:/etc/postgresql/9.4/main$ psql -U postgres -d template1
psql (9.4.5)
Digita "help" per avere un aiuto.
template1=#
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | \
sudo apt-key add -
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install postgresql-9.4 postgresql-contrib pgadmin3
gian@gian:~$ psql -U postgres -d template1
Inserisci la password per l'utente postgres:
psql (9.4.5)
Digita "help" per avere un aiuto.
template1=# \q
gian@gian:~$ psql -U postgres -d template1
Inserisci la password per l'utente postgres:
psql (9.4.5)
Digita "help" per avere un aiuto.
template1=# CREATE ROLE test WITH CREATEDB CREATEROLE LOGIN ENCRYPTED PASSWORD 'testone';
CREATE ROLE
template1=# \du
Lista dei ruoli
Nome ruolo | Attributi | Membro di
------------+-------------------------------------------+-----------
postgres | Superutente, Crea ruoli, Crea DB, Replica | {}
test | Crea ruoli, Crea DB | {}
template1=# Ciao Sotema,I file di configurazione vengono letti all'avvio del server, per cui ogni modifica apportata, affinché diventi effettiva richiede che sia letta dal server. Puoi anche usare il comando: sudo service postgresql reload che non riavvia il server ma lo forza a rileggere la configurazione.
ieri ero stanco e non mi è venuto in mente che avrei potuto (dovuto) riavviare.
Stamattina pare proprio funzionare.
Non mi ero neanche accorto che psql mi parlava in italiano, figo. 8)
:ciao:
I file di configurazione vengono letti all'avvio del server, per cui ogni modifica apportata, affinché diventi effettiva richiede che sia letta dal server. Puoi anche usare il comando: sudo service postgresql reload che non riavvia il server ma lo forza a rileggere la configurazione.
Ciao Gianluigi,
perdona il prolungato silenzio, ma il periodo pre natalizio è per me il peggiore dell'anno.
Riguardo al metodo che suggerisci a me va bene, tenendo conto che giochi al tempo stesso il ruolo del cliente e dello sviluppatore. Non sentirti frustato se non hai ottenuto risposte, vedrai che arrivano.
:ciao:
...
In questi giorni vedo di recuperare del materiale sulle tabelle della contabilità e le posto.
Ciao.
Sono d'accordo con Sotema quando ha parlato dell'installazione del DB che sarebbe meglio che venga fatta attraverso il programma, aggiungerei anche l'implementazione di un sistema di backup dei dati.Sono d'accordo anche io
Riguardo i nomi di campi e tabelle, sono perfettamente d'accordo con chi sostiene di utilizzare i nomi scritti in minuscolo, visto anche, da quello che ho letto che PgSql non "digerisce" il maiuscolo, ma raramente nella mia esperienza gli ho visti scritti in maiuscolo.Ok, ma nelle abbreviazioni tu scrivi cd (codice) invece di id (identificativo) ti va bene id o vuoi cd? A proposito T01 è solo per tua memoria? Significa Tabella 1?
Per quanro riguarda le abbrevazioni di tabelle e campi io le preferisco, vi allego un elenco (non badate all'ordine) di esempi di nomi da cui di solito "pesco" o prendo spunto per i miei progetti, fatemi sapere che ne pensate.Le trovo molto “spinte” e penso mi daranno qualche problema nella comprensione dei costrutti di interrogazione ma credo occorra farci un po l'abitudine e poi... per me vanno bene.
Allego anche alcune considerazioni evidenziate in verde sul documento postato da Gianluigi e commentato da Berserker79.Risposte sia tue che di Berserker79 molto interessanti di cui dovremo discutere più avanti, ma per la maggior parte premature e fuori contesto.
Intanto incomincio ad installare PgSql seguendo la guida e i link postati da Sotema e ci sentiamo a presto.Se hai Ubuntu 14.04 e desideri l'ultimo PostgreSQL stabile (9.4.5) puoi usare il metodo da me seguito ripreso pari pari dalla wiki ufficiale.
Ok, ma nelle abbreviazioni tu scrivi cd (codice) invece di id (identificativo) ti va bene id o vuoi cd? A proposito T01 è solo per tua memoria? Significa Tabella 1?L'elenco postato era solo per darvi un'idea di cosa io intendevo per abbreviazione nomi campi.
Le trovo molto “spinte” e penso mi daranno qualche problema nella comprensione dei costrutti di interrogazione ma credo occorra farci un po l'abitudine e poi... per me vanno bene.Sicuramente a chi non è abituato ad usare questo "metodo" può creare qualche problema, ma niente vieta per esempio di aumentare
Come ho già tentato di spiegare in vari modi occorre che ci diamo un metodo organizzato di lavoro, noto ad esempio che le tue abbreviazioni sono accompagnate da lunghezza di campo e numero di decimali, significa che anche tu in qualche maniera avverti l'esigenza di organizzarti.Certo che sì, prima di iniziare qualsiasi progetto che prevvede l'uso di un DB raccolgo tutte le informazioni che mi permettono di
Non sarebbe male che voi che conoscete i gestionali postaste dei report o diate idea di quali risultati si aspettano certi uffici.Mi spieghi meglio cosa intendi.
Se hai Ubuntu 14.04 e desideri l'ultimo PostgreSQL stabile (9.4.5) puoi usare il metodo da me seguito ripreso pari pari dalla wiki ufficiale.Si, ho Ubunru 14.04 LTS, intendi il wiki ufficiale di Ubuntu ?
PS: Tabella Aziende? Cosa intendete niente Clienti, fornitori ecc.Sarebbe meglio Tabella Azienda, dove memorizzare tutti i dati inerenti la stessa, ragione sociale, sede legale, sede amministrativa,
No intendevo la Wiki di PostgreSQL, vedi un po qui (https://wiki.postgresql.org/wiki/Apt) purtroppo non mi ricordo come ho fatto ad arrivarci. Continuo ad avere problemi con Ubuntu e ho fatto tante di quelle prove...CitazioneSe hai Ubuntu 14.04 e desideri l'ultimo PostgreSQL stabile (9.4.5) puoi usare il metodo da me seguito ripreso pari pari dalla wiki ufficiale.Si, ho Ubunru 14.04 LTS, intendi il wiki ufficiale di Ubuntu ?
CitazionePS: Tabella Aziende? Cosa intendete niente Clienti, fornitori ecc.Sarebbe meglio Tabella Azienda, dove memorizzare tutti i dati inerenti la stessa, ragione sociale, sede legale, sede amministrativa,
partita iva, ecc.. da richiamare per esempio per l'instesatzione di tutti i documenti cartacei che verranno prodotti.
Al singolare, perchè al plurale sembrerebbe che il programma punti ad essere multiazienda, non credo sia il caso di spingerci a questo
livello.
Ciao Gianluigi,Sono d'accordo, purtroppo i miei sono miseri e datatissimi praticamente inutili alla bisogna. Quelli più validi li ha postati Tornu che sono già tanta roba come usa dire.
come hai specificato, vuoi iniziare con l'analisi della documentazione presso il cliente,
quindi sareppe opportuno fare un riepilogo dei documenti necessari a tale scopo, verificando quelli già in nostro possesso, in modo da non reperire dei doppioni.
Cosa ne pensi/pensate?
Per la questione del nome dei campi e delle eventuali abbreviazioni, anche se adesso è prematuro parlarne,Su questo non ho nulla da ridire mi fido di voi, non capisco il motivo pratico della lunghezza fissa, mi spiegate pleace.
dipenderà tutto (credo) dalla decisione di stabilire una lunghezza fissa per il nome del campo, che inevitabilmente obbliga a delle abbreviazioni più o meno estreme.
Ciao.
Io avevo recuperato in rete cose inerenti la contabilità ma mi sono reso conto essere di scarso valore.Non è un problema, l'unica cosa è che non saprei cosa proporre vista la vastità dei programmi di contabilità, se qualcuno mi
Confido molto in voi che lavorate al database.
Aggiungo qui visto che mi sono dimenticato di rispondere a Tornu che occorrerebbe avere campioni di report di analisi delle vendite, quelle cose che studiano gli uffici marketing che poi tirano giù grafici ecc. :rolleyes:Idem come sopra, perchè si spazia dalle normali analisi di acquisto, venduto, rotazione, ecc... fino ad arrivare alla Business Intelligence
Cose di questo genere.
Per la questione del nome dei campi e delle eventuali abbreviazioni, anche se adesso è prematuro parlarne,
dipenderà tutto (credo) dalla decisione di stabilire una lunghezza fissa per il nome del campo, che inevitabilmente obbliga a delle abbreviazioni più o meno estreme.
Ciao.
Su questo non ho nulla da ridire mi fido di voi, non capisco il motivo pratico della lunghezza fissa, mi spiegate pleace.Se hai guardato attentamente la lista di campi che ho postato come esempio avrai notato che più o meno la lunghezza
Come detto penso che dopo un po ci si abitua
:ciao:
Non è un problema, l'unica cosa è che non saprei cosa proporre vista la vastità dei programmi di contabilità, se qualcuno miDi contabilità non so nulla, Tieni però conto che Rubinetto Felice è una piccolissima azienda avrà in tutto una dozzina di impiegati e neanche dieci rappresentanti di commercio nei suoi momenti di massimo splendore.
dice che tipo di documenti vedo di procurarli.
...
Idem come sopra, perchè si spazia dalle normali analisi di acquisto, venduto, rotazione, ecc... fino ad arrivare alla Business Intelligence
Se hai guardato attentamente la lista di campi che ho postato come esempio avrai notato che più o meno la lunghezza
dei nomi dei campi è uguale, questione di pulizia e ordine. Non so a te, ma a me è capitato di aver visto dei DB con nomi di
campi da 5 a 20 caratteri, inguardabili.
Ciao Gianluigi,
non hai ancora digerito le abbuffate (...dici la verità ;D) di queste festività che già ti sei rimesso a lavoro.
Do uno sguardo alla documentazione che hai postato...ci sentiamo presto :ciao:
@Sotema,
forte il suggerimento rivolto agli oggetti, era mia intenzione iniziale che progettassimo un database generico adatto a qualunque marca di database come raccomanda Hernandez, in effetti non ha senso visto che abbiamo scelto PostgreSQL e allora ti chiedo ma poi con SQL come si interroga una tabella ereditata?
SELECT rasaz, indaz, idtcl FROM anacli ;Come si disegna nello schema?vedi allegato, nello schema studente, disoccupato e lavoratore ereditano persona.
A proposito di campi dimenticati:Il Numero Registro Imprese corrisponde al Codice Fiscale (non la partita iva a meno che questa sia uguale al CF); la modifica è stata introdotta dal DPR 586 del 14 dicembre 1999. Aggiungerei invece il campo REA (Numero di Repertorio delle notizie Economiche e Amministrative del Registro delle Imprese). Mentre il numero RI è unico a livello nazionale e assegnato dalla CCIAA della provincia in cui risiede la sede legale, il numero REA è diverso per ogni provincia/CCIAA in cui apri una sede/unità locale. Di conseguenza apporterei le seguenti modifiche:
Per l'azienda aggiungo un campo registro imprese?
seguire i risultati di calcio mentre si valuta un gestionale forse non è così conveniente.
Propongo anche l'ennesima possibile relazione, non mi convince in quanto i magazzini non credo abbiano REA, Codice Fiscale, sito web...
:ciao:
Ciao Gianluigi,Ciao Sotema,
penso ti stia ingarbugliando.
Che senso ha porre dei vincoli nella tabella anazie verso anacli, anafor,... quando queste sono già legate ad anazie tramite idazi? Non so perché avevi pensato alle tabelle anacli e anafor, forse per separare nettamente clienti e fornitori? IN questo caso ti suggerisco di inserire i campi codcl (codice cliente) e codfo (codice fornitore) dati da stampare obbligatoriamente sui documenti fiscali. Se poi predisponi una tabella listini (altra bella storia), potresti collegarla ad anacli per gestire le condizioni di vendita. La tabella anavet potresti popolarla con i campi relativi a Luoghi di consegna (potrebbe essere un corriere locale, regionale o nazionale) ed i relativi costi; la qualcosa potrebbe tornare utile in sede di preventivo. Anche i tempi di presa e consegna possono differire da un vettore all'altro.
Non comprendo invece lo scopo della tabella anazia.Come detto la nostra azienda avrà un logo e dati particolari da esporre nei documenti o no? Tutto ciò che è particolare va messo nella tabella specifica tutto ciò che è comune nella tabella anazie, sempre parlando di relazioni 1:1 invece per le relazioni 1:N le cose cambiano.
Le sedi decentrate, siano esse magazzini o uffici, detengono un diverso Numero REA se risiedono in una provincia diversa dalla sede legale, facendo quindi capo ad una differente CCIAA.Significa che la tavola relazionale "NuovaRelazioneAziendale" ti convince? Mi era parso di no. :P
Ciao Sotema,Come vedi anche io non scherzo coi tempi...
scusa il ritardo della risposta, ma sono dovuto uscire e rientro solo adesso.
mi appare oscuro il motivo di inserire idcli al posto di idtcl (ID Tipologia Cliente) che avrebbe dovuto catalogare i clienti in base all'importanza e che potrebbe essere utile per la scontistica.Non avevo intuito che la t in idtcl stava per 'tipo', pensavo ad un errore di scrittura.
Ti ripeto la mia perplessità circa la tabella anamag da cambiare in anasedi sembra una ripetizione della tabella anazie quali campi reputi indispensabili in essa? Quali superflui?Se lo scopo della tabella anasedi è catalogare le varie sedi (siano esse magazzini o no) delle aziende contenute in anazie, allora dovrai registrarvi i dati fiscali di ciascuna sede; se poi la sede di cui parliamo è un filiale di Rubinetto Felice il Numero REA, che sarà differente da quello della sede centrale qualora la sede sia residente in una provincia diversa, deve necessariamente essere registrato poiché deve comparire nei documenti fiscali emessi dalla filiale. Per chiarire il concetto :
Per quale motivo non è sufficiente il codice azienda (idazi)?Se ti riferisci ad ulagg e utagg devono comparire in anacli per eventuali attività di audit. (chi ha fatto cosa?)
Come vedi anche io non scherzo coi tempi...Caro Sotema cari tutti,
Purtroppo ancora adesso dopo averne parlato con te non ho chiaro se REA debba essere memorizzato solo per la nostra organizzazione o anche per le altre aziende: Clienti, fornitori ecc.Allora facciamo luce...
Tu e Sotema intendete soltanto rovesciare il concetto? Evitare di avere tanti campi vuoti (se un anazie è cliente, fornitore vettore e organizz. saranno vuoti), è così?Quello che io, e credo Berseke79, intendo dire è che non serve una chiave primaria nelle tabelle clienti, fornitori e vettori, in quanto hai già la chiave primaria in anazie. Proprio per questo motivo ti accennavo alle tabelle ereditate. Una tabella figlia eredita tutti i campi dalla tabella madre; per cui ne deriva che se la tabella clienti eredita anazie, ne eredita anche la chiave primaria. In soldoni:
Ciao Gianluigi,
dovresti rivedere la relazione fra anazie e ansedi, secondo me va tolta dalla tabella anazie il campo idsed, mentre va inserito nella tabella ansedi il campo idazi.
Come dice Sotema, su ansedi vanno inserite tutte le sedi dell'azienda diverse da quella legale, che va indicata nella tabella anazie.
Ma la tabella ansedi, dovrebbe contenere i dati delle sedi extra dei nostri clienti/fornitori o della nostra azienda?
Se è stata pensata per i nostri clienti/fornitori, credo che si possa evitare utilizzando solo le due tabelle principali clienti e fornitori.
Se lo scopo della tabella anasedi è catalogare le varie sedi (siano esse magazzini o no) delle aziende contenute in anazie, allora dovrai registrarvi i dati fiscali di ciascuna sede; se poi la sede di cui parliamo è un filiale di Rubinetto Felice il Numero REA, che sarà differente da quello della sede centrale qualora la sede sia residente in una provincia diversa, deve necessariamente essere registrato poiché deve comparire nei documenti fiscali emessi dalla filiale. Per chiarire il concetto :
Spedizione a Sede o Magazzino di un cliente
Sui documenti fiscali dovranno apparire:
Per Rubinetto Felice
Ragione Sociale
Indirizzo Sede Legale (Via - Comune - CAP - Provincia)
Codice Fiscale e Partita IVA (qualora differenti devono apparire entrambi)
Numero REA
Numero CCIAA
Per il Cliente
Ragione Sociale
Indirizzo Sede Legale (Via - Comune - CAP - Provincia)
Codice Fiscale e Partita IVA (qualora differenti devono apparire entrambi)
Indirizzo di spedizione Merce (se diverso dall' indirizzo della sede legale)
I dati relativi alle sedi diverse dalla Sede Legale, li metti in anasedi, per non avere la tabella anazie piena di campi nulli.
Ovviamente i dati delle Sedi Legali saranno in anazie.
SELECT *
FROM anazie, anacli
WHERE anazie.idcli = anacli.idcli
AND anazie.proaz = 'RM'SELECT *
FROM anazie
INNER JOIN anacli
ON anazie.idcli = anacli.idcli
WHERE anazie.proaz = 'RM'SELECT *
FROM anazie
WHERE anazie.proaz = 'RM'
AND idcli IS NOT NULLSELECT rasaz, indaz,telaz
FROM anazie
INNER JOIN anacli
ON anazie.idcli = anacli.idcli
WHERE anazie.proaz = 'RM'SELECT anazie.rasaz,anazie. indaz, anaper.cogpe, anaper.telpe
FROM (anazie
INNER JOIN anacli
ON anazie.idcli = anacli.idcli)
INNER JOIN anaper
ON anaper.idazi= anazie.idazi
WHERE anazie.proaz = 'RM'SELECT anazie.rasaz,anazie. indaz, anaper.cogpe, anaper.telpe
FROM anazie, anaper, anacli
WHERE anazie.idcli = anacli.idcli
AND anazie.idazi = anaper.idazi
AND anazie.proaz = 'RM'Ciao Sotema,Dove sta il problema?
sono bloccato, ho trovato un'incongruenza fra la tabella clienti e la tabella sedi.
La tabella sedi ha come chiave primaria idsede come può essere anche chiave esterna lato molti per la tabella clienti? :rolleyes:
:ciao:
Ciao Sotema,Dove sta il problema?
sono bloccato, ho trovato un'incongruenza fra la tabella clienti e la tabella sedi.
La tabella sedi ha come chiave primaria idsede come può essere anche chiave esterna lato molti per la tabella clienti? :rolleyes:
:ciao:
La chiave esterna per la tabella clienti è un vincolo referenziale; ti vieta di assegnare per un Cliente una Sede che non esiste nella tabella Sedi. Se poi volessi cancellare un Cliente (cosa per altro da evitare quasi sempre) ti permette di cancellarne in automatico (ON DELETE CASCADE) anche tutte le sedi corrispondenti.
:ciao:
Vorrei far notare che con questo semplice schema ad esempio si possono registrare per ogni cliente tutti i punti di consegna che vogliamo;I punti di consegna dove vanno inseriti? Su una delle tabelle di cui abbiamo discusso o su una ancora da progettare?
...proprio non riesco a concepire una tabella che contiene records che hanno un significato a seconda di quale colonna è valorizzata (idcli, idfor, ecc..)...Scusa ma che modo è di descrivere le foreign key? Quello li è il metodo più solido e sicuro di legare dati fra due tabelle, non esiste metodo più certo, puoi stare tranquillo al 100% che quanto è scritto il quella tupla è parte integrante dei record della tabella “madre”.
Mi stupisce poi che proprio tu dica questo di una tabella che comunque è ben suddivisa in campi mono dato con record solidamente collegati alle tabelle “madri”, non sei tu colui che ha parlato di grandi tabelle suddivise in “mini tabelle” con campi pluridato che gestiscono tutta l'attività del database professionale su cui lavori?Ciao Gianluigi, la tabella contenente le mini tabelle, di cui ti avevo parlato, serve solo per gestire tutte quelle entità che si possono esprimere con pochissimi campi, ad esempio il campo codice e il campo descrizione. Tutte le altre entità, che possiedono molti campi, sono gestite tramite "classiche" tabelle dedicate.
Citazione...proprio non riesco a concepire una tabella che contiene records che hanno un significato a seconda di quale colonna è valorizzata (idcli, idfor, ecc..)...Scusa ma che modo è di descrivere le foreign key? Quello li è il metodo più solido e sicuro di legare dati fra due tabelle, non esiste metodo più certo, puoi stare tranquillo al 100% che quanto è scritto il quella tupla è parte integrante dei record della tabella “madre”.
\c test_felixDROP TABLE [ IF EXISTS ] nome [, ...] [ CASCADE | RESTRICT ]Dovete cancellare per prima anaper, poi banche quidi anazie e anavet almeno credo da qui in poi finiscono i vincoli.
DROP DATABASE [ IF EXISTS ] nome
Ciao Gianluigi, mi puoi dare qualche conferma sul nuovo schema?
Vediamo se ho capito la nuova relazione.
Sia i clienti, i fornitori e i vettori hanno partita iva e codice fiscale direttamente nelle tabelle principali (anacli, anafor e anavet), mentre tramite le tabelle unicli, unifor e univet registriamo tutte le varie sedi che vanno dalla sede legale, alla sede amministrativa, ai vari punti di consegna/ritiro, ecc...
Mentre le tabelle anaorg e uniorg, sono utilizzate per la gestione della nostra azienda/sedi.
Questo schema mi piace e mi sembra una buona base su cui lavorare.:ok: Allego il file SVG creato da Inkscape.
Fammi sapere, ciao.
P.S.: potresti allegare il file modificabile al posto del pdf?!
Ti ringrazio pertanto dei nuovi dati, l'unico appunto che ti faccio è che se davi migliori dettagli magari capivo anche io a cosa servono certi campi nelle tue tabelle.Scusa, hai ragione. Ti allego le stesse tabelle corrette e commentate.
Una curiosità però ce la devi togliere, se tutti i dati dei clienti li tieni in un'unica tabella come fai a conservare di quel cliente le eventuali sedi secondarie che non siano dei meri indirizzi di consegna?Dai uno sguardo alla tabella INDSPE, puoi inserire tutte le destinazioni che vuoi diverse dalla sede legale.
Come fai a rammentare, per un cliente importante, i 25 addetti alle varie mansioni utili a tenere le giuste relazioni?Scusa, mi spieghi praticamente a che servirebbe avere questi dati?
Comunque sia anche tu dividi in due tabelle, no????
Le mie sono solo idee da valutare, magari sto scrivendo un mare di sciocchezze ma gli americani che sono maestri fanno proprio questo quando discutono su qualcosa, se gli viene un'idea la dicono magari non vale niente ma può far scattare in un altro l'idea giusta.:ok:
Caro Sotema io senza il tuo fondamentale apporto non ho intenzione di proseguire la discussione, non intendo mancare di rispetto agli altrettanto indispensabili Berserker79 e Tornu ma senza l'unico che conosce a fondo PostgreSQL ditemi voi come potremmo fare ad andare avanti, e poi non è solo per questo.Spero che Sotema non abbia mollato solo per divergenze di vedute (si può sempre trovare una soluzione), non ci credo, magari la sua assenza e dettata da impegni lavorativi, famiglia...come capita anche a me ed altri...
Ciao Tornu,Ci mancherebbe, anche tu pur avendo tempo libero avrai comunque impegni e cose da fare...come tutti
scusa il ritardo ma ho un impegno che mi occupa tutto il giorno e mi lascia parecchio svuotato, per ora inizio col chiedere questo:
Campo in più per ragione sociale, perché non allargare il primo a 70? che vantaggi si hanno ad avere due campi?Dipende da come disegnerai la Form che prevederà questo campo.Io di solito preferisco due righe (TextBox) ed utilizzare la seconda se la ragione sociale eccede la prima, che una molto lunga che contenga tutta la ragione sociale. Pensa a quando implementerai la stampa
IDLOC: Non è troppo limitante? Capisco la necessità di evitare errori di immissione ma così impedisci di registrare clienti, vettori e fornitori stranieri, penso occorra trovare un'altra strada.La tabella sarà editabile, e quindi potrai sempre inserire anche una località straniera.
In una tabella parli di valuta ma così non può che essere solo quella nazionale.Europea... a meno che non fai export extra europeo non so se è il caso di prevedere altre valute, anche se io ho indicato la tabella, confrontiamoci.
Partita Iva del vettore, se è obbligatoria quella del fornitore, presumo lo sarà anche questa, sempre di un fornitore si tratta anche se di servizio.Mi devo informare, ma nel mio lavoro spesso e volentieri le bolle che mi passano in mano raramente riportano la partita iva del vettore.
Ripeto io di gestionale nulla saccio ma credo che se ad esempio hai come cliente un'Italsider, che deve voler dire avere per cliente una città intera, immagino tu abbia bisogno di parecchio spazio per prendere nota dei vari contatti a più livelli. Devi trovare un modo per poterlo fare, io ne ho proposto uno. Grazie alle correlazioni fra tabelle ci sono altri modi per farlo ma non ho capito tu come faresti.Ti assicuro che nel lavoro quotidiano i contatti che ti servono con un cliente di solito sono uno a uno, con un fornitore di solito ai a che
Mancano le (o la) tabelle del personale sempre che tu le preveda, come interagisce?Mi spieghi praticamente a cosa può servire.
Quando parlo che anche tu spalmi i dati su più tabelle intendo IDLOC ad esempio, ma principalmente Indirizzi di spedizione, ma è normale visto che è la peculiarità del database relazionale. Il database relazionale rifugge solo dati non omogenei che impedirebbero le interrogazioni.Beh, non è proprio spalmare, ma la normale relazione tra tabelle di un database utilizzando le chiavi primarie delle stesse.
Sotema più che altro potrebbe essersi rotto di spiegare concetti difficili a un vaso di coccio come me. :'(Non credo che l'assenza (spero momentanea) di Sotema sia per il motivo indicato da te...la suocera ? ;D
Il fatto è che mi aveva assicurato che abitando vicino alla suocera...
Io PostgreSQL non vorrei proprio abbandonarlo, me ne sono innamorato :-[
:ciao: :ciao: :ciao:
CitazioneCampo in più per ragione sociale, perché non allargare il primo a 70? che vantaggi si hanno ad avere due campi?Dipende da come disegnerai la Form che prevederà questo campo.Io di solito preferisco due righe (TextBox) ed utilizzare la seconda se la ragione sociale eccede la prima, che una molto lunga che contenga tutta la ragione sociale. Pensa a quando implementerai la stampa dei documenti, ti eviterai di utilizzare funzioni che spezzino il dato in due.
CitazioneIDLOC: Non è troppo limitante? Capisco la necessità di evitare errori di immissione ma così impedisci di registrare clienti, vettori e fornitori stranieri, penso occorra trovare un'altra strada.La tabella sarà editabile, e quindi potrai sempre inserire anche una località straniera.
CitazioneIn una tabella parli di valuta ma così non può che essere solo quella nazionale.Europea... a meno che non fai export extra europeo non so se è il caso di prevedere altre valute, anche se io ho indicato la tabella, confrontiamoci.
CitazionePartita Iva del vettore, se è obbligatoria quella del fornitore, presumo lo sarà anche questa, sempre di un fornitore si tratta anche se di servizio.Mi devo informare, ma nel mio lavoro spesso e volentieri le bolle che mi passano in mano raramente riportano la partita iva del vettore.
Non è un fornitore, a meno che non ti fatturi dei servizi, in questo caso lo inserisci come fornitore.
CitazioneRipeto io di gestionale nulla saccio ma credo che se ad esempio hai come cliente un'Italsider, che deve voler dire avere per cliente una città intera, immagino tu abbia bisogno di parecchio spazio per prendere nota dei vari contatti a più livelli. Devi trovare un modo per poterlo fare, io ne ho proposto uno. Grazie alle correlazioni fra tabelle ci sono altri modi per farlo ma non ho capito tu come faresti.Ti assicuro che nel lavoro quotidiano i contatti che ti servono con un cliente di solito sono uno a uno, con un fornitore di solito ai a che
fare al massimo con il responsabile commerciale, comunque nessun problema basta prevedere una tabella tipo Rubrica Clienti/Fornitori
dove andrai ad inserire tutti i contatti che ti servono. Appena ho un attimo la cerco (c'è l'ho gà pronta da qualche parte) e la posto così capirai meglio cosa intendo.
CitazioneMancano le (o la) tabelle del personale sempre che tu le preveda, come interagisce?Mi spieghi praticamente a cosa può servire.
CitazioneQuando parlo che anche tu spalmi i dati su più tabelle intendo IDLOC ad esempio, ma principalmente Indirizzi di spedizione, ma è normale visto che è la peculiarità del database relazionale. Il database relazionale rifugge solo dati non omogenei che impedirebbero le interrogazioni.Beh, non è proprio spalmare, ma la normale relazione tra tabelle di un database utilizzando le chiavi primarie delle stesse.
Non credo che l'assenza (spero momentanea) di Sotema sia per il motivo indicato da te...la suocera ? ;D
Per quanto riguarda il DB ti capisco, ma io ho sempre lavorato con Mysql, piacerebbe anche a me apprendere Postgresql,
si può sempre studiare, anche se l'apporto di una persona che lo conosce è un'altra cosa.
Scusa sai ma questa la capisco poco. Io i form di solito li basavo su una vista che mi permetteva di incasellare bene il tutto.Mi spieghi praticamente cosa intendi.
Comunque non trovo nulla di difficoltoso a lavorare con Gambas su una stringa.Ti assicuro di no, comunque non credo sia un problema adottare l'una o l'altra.
Trovo invece complicato gestire interrogazioni con più campi per lo stesso dato.
IDLOC: Non è troppo limitante? Capisco la necessità di evitare errori di immissione ma così impedisci di registrare clienti, vettori e fornitori stranieri, penso occorra trovare un'altra strada.Dai un'occhiata alla tabella località che ho allegato.
Dovremo aggiungere nazione e sigla nazione. Mi puoi spiegare come funziona.
Anche Inghilterra e metà Russia sono in Europa e poi con internet...Dipende tutto dall'utenza a cui vogliamo rivolgere il gestionale, per quanto riguarda internet non credo tu voglia
Ma i vettori che vi consegnano la merce in porto franco ve lo fanno gratis?Se la consegna è in porto franco, vuol dire che il trasporto lo paga il fornitore. Se la consegna è in porto franco con addebito in fattura
Ahi iniziamo a dover aggiungere una nuova tabella ;DSai quante ne dovremmo aggiungere ancora, non siamo neanche agli inizi.... ;D
Veramente ne avevo già parlato per quanto riguarda i clienti. Avere la possibilità di conoscere la data di nascita di qualcuno ti permette di potergli fare gli auguri di Buon Compleanno magari recapitandoli a casa accompagnati da un vassoio di arantzade ;D??? ???
Per fare un esempio, col mio schema, la valuta la otterresti dalla banca di appoggio della fattura. Non servirebbe marcarla nella tabella del cliente.E se hai un cliente che paga solo contanti, o con rimessa diretta come gli agganci la valuta?
Speriamo si faccia vivo e comunque... continuiamo a studiare...:coder:
:ciao: :ciao: :ciao:
Intendo che con Access se ben ricordo c'erano delle semplificazioni a creare maschere o widget legati a campi di tabelle o viste (query) e siccome le maschere normalmente si riferiscono a più tabelle...
Mi spieghi praticamente cosa intendi.
Dai un'occhiata alla tabella località che ho allegato.Mi farò uno schema e poi ti dico.
Dipende tutto dall'utenza a cui vogliamo rivolgere il gestionale, per quanto riguarda internet non credo tu vogliaSono d'accordo ma appare più corretto prevedere un'espansione dell'azienda e quindi prevenirla.
arrivare a fare interagire il gestionale con un ecommerce, credo che sia un tantino oltre i nostri obiettivi.
Se la consegna è in porto franco, vuol dire che il trasporto lo paga il fornitore. Se la consegna è in porto franco con addebito in fatturaIntendevo le consegne ai clienti che se fatte in porto franco poi il vettore ce le fattura a noi.
io non pago il vettore ma il fornitore che mi addebiterà il costo del trasporto in fattura.
Sai quante ne dovremmo aggiungere ancora, non siamo neanche agli inizi.... ;DSi, so che dobbiamo aggiungere parecchie tabelle ma intendevo “aggiungere per completare le vecchie tabelle già esistenti e non sufficienti a contenere tutto”. :P
??? ???Se non capisci cosa intendo vuol dire che non sai il significato di relazioni pubbliche. :-X
E se hai un cliente che paga solo contanti, o con rimessa diretta come gli agganci la valuta?Ma io ripeto non so niente e tanto meno di amministrazione, ma dubito fortemente che tu possa vendere all'estero in contanti o per rimessa diretta. Io credo ci si appoggi alle banche, ma ripeto non ne so nulla, ed è per questo che senza persone che ne sanno a fondo andremo poco lontano.
Con il tuo schema una banca una valuta ?
E se due clienti diversi hanno la stessa banca ma valuta diversa?
Per come l'ho pensata io le valute sono un dato indipendente dalle banche.
:coder::coder:
:ciao: Premetto per ora non ci sono novità, scusate. :-[
Volevo solo fare alcune considerazioni su questa discussione e dire che mi dispiacerebbe morisse qui.
Non nego di averci pensato ma credo che non sarebbe giusto, naturalmente se avrò ancora il vostro sostegno altrimenti mi sarebbe impossibile continuare.
Ho dovuto rivedere i miei piani, inizialmente avevo pensato di sospendere la scrittura del libro e dedicarmi a questo, ma mi rendo conto che la cosa non è fattibile essendo questa, comunque vada, una discussione di “lungo respiro”.
Attualmente sono impegnato in altre cose anche extra Gambas, appena avrò qualcosa mi rifarò vivo.
Nella speranza di non avervi perso, vi saluto caramente.
:ciao: :ciao: :ciao: