Autore Topic: Sviluppo Gestionale Rubinetto Felice  (Letto 14188 volte)

Offline Gianluigi

  • Moderatore globale
  • Senatore Gambero
  • *****
  • Post: 4.157
  • Tonno verde
    • Mostra profilo
Re:Sviluppo Gestionale Rubinetto Felice
« Risposta #30 il: 10 Novembre 2015, 00:50:44 »

Hai dato un'occhiata al link che ti ho segnalato? Contienela documentazione, versione 9.1, quasi completamente tradotta in italiano.
 :ok:

Ciao Sotema,
certo che ho studiato in italiano li dove mi hai indicato altrimenti non avrei capito nulla del tutto.  :rolleyes:
Ho creato una tabella con la primary key auto incrementale usando il tipo serial, invece con CREATE SEQUENCE che ho la possibilità di impostare la key in vari modi non sono riuscito a farla funzionare, cioè sono riuscito a creare la sequenza dandogli un nome sono riuscito a creare la tabella con la primary key di quel tipo ma poi non riesco a popolarla.
Ora è tardi domani riprovo.
La Sequence sul tuo tutorial è stata creata così?
Ho anche creato uno schema, mi pareva di aver capito che non necessitava scriverne il nome per qualificare la tabella se questa era univoca ma invece... con public puoi non specificarlo ma con gli altri schemi devi, giusto o sbaglio qualcosa?
Sai ho sempre lavorato su database in uso esclusivo (più o meno) pertanto non ho mai considerato se non superficialmente le difficoltà che si possono incontrare solo a incrementare una chiave in uno scenario dove possono tentare di farlo contemporaneamente centinaia di persone.
Accidenti quanti tipi di dato supporta PostgreSQL!
Sto attraversando momenti di vero sconforto, ho paura (anzi ne sono certo) di essere troppo scemo per un programma così raffinato, mi sento così fuori luogo... speriamo bene.
Già mi sentivo inadeguato con SQLite, figurati...
Va bene bando alle ciance, che domani si ricomincia sempre che riesca un po a riposare  :sleepy:
 :ciao:
nuoto in attesa del bacio di una principessa che mi trasformi in un gambero azzurro

Offline Gianluigi

  • Moderatore globale
  • Senatore Gambero
  • *****
  • Post: 4.157
  • Tonno verde
    • Mostra profilo
Re:Sviluppo Gestionale Rubinetto Felice
« Risposta #31 il: 10 Novembre 2015, 16:17:51 »

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:
nuoto in attesa del bacio di una principessa che mi trasformi in un gambero azzurro

Offline Gianluigi

  • Moderatore globale
  • Senatore Gambero
  • *****
  • Post: 4.157
  • Tonno verde
    • Mostra profilo
Re:Sviluppo Gestionale Rubinetto Felice
« Risposta #32 il: 10 Novembre 2015, 16:51:54 »
Ciao sotema,
mi occorre aiuto, non riesco a far funzionare questa tabella con la quale volevo studiare SEQUENCE.
Ho creato il database mio_test di proprietà di test ho creato lo schema mioschema e due tabelle entrambe auto incrementali.
La prima mioschema.fornitori usando serial per la primary key (ci ho provato anche un unique),  questa funziona  con queste prove di inserimento agendo da terminale mio_test=> (nota: ho fatto casino con nome e cognome scusa ma ai fini pratici...):
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.

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?

La seconda tabella mioschema.fornitori usando SEQUENCE così al momento di popolarla ottengo questi errori:

Codice: [Seleziona]
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).

È perché ho esagerato con una sequenza cortissima? Bisogna indicare il tipo di valore, ma come?
 :rolleyes:  :rolleyes:  :rolleyes:

Comunque anche a far paciughi mi diverto un sacco  :coder:  :hatecomputer:
 :ciao:
« Ultima modifica: 10 Novembre 2015, 16:55:51 da Gianluigi »
nuoto in attesa del bacio di una principessa che mi trasformi in un gambero azzurro

Offline Berserker79

  • Grande Gambero
  • ***
  • Post: 201
    • Mostra profilo
Re:Sviluppo Gestionale Rubinetto Felice
« Risposta #33 il: 10 Novembre 2015, 19:50:38 »

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:

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.

Offline Gianluigi

  • Moderatore globale
  • Senatore Gambero
  • *****
  • Post: 4.157
  • Tonno verde
    • Mostra profilo
Re:Sviluppo Gestionale Rubinetto Felice
« Risposta #34 il: 11 Novembre 2015, 00:34:59 »

Ciao, nella tabella degli ordini metti anche il prezzo in modo da avere accesso immediatamente all'informazione evitando join fra le tabelle dei listini.
:ok:  me lo aveva detto anche Tornu, Sotema lo aveva confermato, mi arrendo  :D
Citazione
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?

Citazione
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.
:ok:
Grazie
 :ciao:
nuoto in attesa del bacio di una principessa che mi trasformi in un gambero azzurro

Offline Gianluigi

  • Moderatore globale
  • Senatore Gambero
  • *****
  • Post: 4.157
  • Tonno verde
    • Mostra profilo
Re:Sviluppo Gestionale Rubinetto Felice
« Risposta #35 il: 11 Novembre 2015, 00:45:01 »
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?
nuoto in attesa del bacio di una principessa che mi trasformi in un gambero azzurro

Offline sotema

  • Maestro Gambero
  • ****
  • Post: 467
    • Mostra profilo
Re:Sviluppo Gestionale Rubinetto Felice
« Risposta #36 il: 11 Novembre 2015, 23:55:56 »
Ciao Gianluigi purtroppo in questi giorni non ho possibilità di usare internet e sto scrivendo dal cellulare. Nel fine settimana ti chiarirò i dubbi.
L'uomo ha inventato la bomba atomica, ma nessun topo al mondo costruirebbe una trappola per topi.
Albert Einstein

Offline Gianluigi

  • Moderatore globale
  • Senatore Gambero
  • *****
  • Post: 4.157
  • Tonno verde
    • Mostra profilo
Re:Sviluppo Gestionale Rubinetto Felice
« Risposta #37 il: 12 Novembre 2015, 10:59:12 »
Carissimo sotema,
nessunissimo problema ad attendere, prima cosa perché non ci insegue nessuno, secondariamente ne approfitterò per cercare di studiare un po meglio PostgreSQL  :D
Se poi dovessi aggiungere qualche nuovo dubbio non ti preoccupare è anche un modo di studiare chissà che poi non riesca anche a trovare la risposta  :rolleyes: :mad:
Lo abbiamo già detto ma è sempre utile ribadirlo, il tempo che dedichiamo a Gambas & Co. è ritagliato da impegni più importanti e pressanti, è una delle nostre aree di svago e finché rimarrà tale  prima o poi ci ritorneremo felici di farlo, ma è chiaro che non si possono dare tempi certi.
Pensandoci bene questa discussione potrebbe anche evolversi in qualcosa di più utile ma, come usa dire, meglio è non mettere il carro davanti ai buoi.
 :ciao:
nuoto in attesa del bacio di una principessa che mi trasformi in un gambero azzurro

Offline sotema

  • Maestro Gambero
  • ****
  • Post: 467
    • Mostra profilo
Re:Sviluppo Gestionale Rubinetto Felice
« Risposta #38 il: 14 Novembre 2015, 16:27:53 »
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.

Nella tabella hai creato il campo ID_Imp specificando come tipo di dato SERIAL, che è uno speciale tipo di INTEGER ad autoincremento. Quando specifichi il tipo SERIAL per un campo PostgreSQL crea automaticamente una sequenza associata ad esso per generare il valore che andrà immesso nel recordo successivo. In effetti le istruzioni:
Codice: [Seleziona]
CREATE TABLE fornitore
(
  fornitore_id serial,
  ...
);

oppure
Codice: [Seleziona]
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),
  ...
)

sortiscono lo stesso effetto. Ad ogni inserimento di record nella tabella il campo fornitore_id verrà incrementato di un intero.

Il vantaggio di utilizzare una sequenza personalizzata consiste nel fatto che puoi determinare quale sia il valore dell'incremento.
Codice: [Seleziona]
CREATE SEQUENCE fornitore_id_seq
  INCREMENT 2
  MINVALUE 1
  MAXVALUE 9223372036854775807
  START 1
  CACHE 1;
genera una successione di soli interi dispari.   ;)

L'incremento è inteso in senso algebrico.
Codice: [Seleziona]
CREATE SEQUENCE prova_id_seq
  INCREMENT -1
  MINVALUE 10
  MAXVALUE 1000
  START 1000
  CACHE 1;
genera una squenza decrementale.  ;D

Citazione
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.
Citazione
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?

Penso ti riferisca ai metodi del componente gb.db come Connection.Find, Connection.Edit ... il quale ha lo scopo di creare un livello intermedio tra l'applicazione ed il database. Non sapendo a priori quale DB userai (SQLite, MySQL,PostgreSQL) questi metodi ti sono di notevole aiuto, poichè non dovrai modificare il codice per adattarlo ad eventuali realtà differenti. Sarà Gambas a convertire l'istruzione nella sintassi corretta.
Se diversamente stai scrivendo una applicazione che utilizzerà solo e comunque uno specifico DB, allora con il comando Connection.Exec("istruzione sql") potrai ottenere un maggior controllo al costo di qualche riga di codice (ed eventuali errori) in più.
Libero arbitrio.... 8)

Citazione
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.
Chiaro?
Infine NO il privilegio di SUPERUSER non può ssere cambiato al volo. Puoi assegnarlo nella fase di creazione dell'utente o utilizzare in seguito l'istruzione
Codice: [Seleziona]
ALTER ROLE nomeutente WITH SUPERUSER;

L'uomo ha inventato la bomba atomica, ma nessun topo al mondo costruirebbe una trappola per topi.
Albert Einstein

Offline Gianluigi

  • Moderatore globale
  • Senatore Gambero
  • *****
  • Post: 4.157
  • Tonno verde
    • Mostra profilo
Re:Sviluppo Gestionale Rubinetto Felice
« Risposta #39 il: 14 Novembre 2015, 17:50:05 »
Ciao Sotema,
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]
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                         | {}
Ma il comando di psql (\copy) può essere usato da Gambas con exec?
 :ciao:

PS: mi scuso col Manzoni per aver confuso un suo personaggio con la spiaggia di Palermo  :-[
nuoto in attesa del bacio di una principessa che mi trasformi in un gambero azzurro

Offline sotema

  • Maestro Gambero
  • ****
  • Post: 467
    • Mostra profilo
Re:Sviluppo Gestionale Rubinetto Felice
« Risposta #40 il: 14 Novembre 2015, 19:35:08 »
Ciao Sotema,
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]
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                         | {}
Ma il comando di psql (\copy) può essere usato da Gambas con exec?
 :ciao:

PS: mi scuso col Manzoni per aver confuso un suo personaggio con la spiaggia di Palermo  :-[
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';
L'uomo ha inventato la bomba atomica, ma nessun topo al mondo costruirebbe una trappola per topi.
Albert Einstein

Offline Berserker79

  • Grande Gambero
  • ***
  • Post: 201
    • Mostra profilo
Re:Sviluppo Gestionale Rubinetto Felice
« Risposta #41 il: 15 Novembre 2015, 06:16:11 »
Citazione
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?


Ciao,
mettiamo che tu abbia due categorie di punti vendita, una categoria per punti vendita di piccoli dimensioni con un tipo di assortimento di articoli alla vendita, e l'altra per punti vendita di grandi dimensioni con un assortimento di articoli più ampio.
Mettiamo che per i primi pv utilizzerai il listino AAA e per i secondi il listino BBB.
Ad un certo punto, decidi di utilizzare per tutti i pv il listino BBB, quindi il listino AAA non verrà più utilizzato.
Il listino AAA va lasciato comunque in modo da trovare i dati per interogazioni sui pv della prima categoria, in date in cui avevano associato il listino AAA.
Nel caso si decida di non utilizzare più il listino AAA e che questo non debba essere più visibile nel gestionale per l'uso da parte del personale, si può abilitare un campo  che indica che quel listino non è più valido e quindi il gestionale, sa che deve scartarlo.
Prima di cancellare effettivamente dei record, bisogna considerare l'importanza del tipo di dato. Ad esempio, la tabella degli ordini clienti è gestita in modo che un ordine se cancellato, può essere ripristinato.
Questo perchè le righe non vengono cancellate veramente, ma viene attivato un campo che sta ad indicare se il record è cancellato o no.
Nel caso dei listini, io farei la stessa cosa, terrei tutto quello creato. Proprio questo fine settimana ho dovuto valorizzare dei movimenti a partire dal 2011 ad oggi, ripescando il prezzo associato ad ogni articolo per ogni movimento giornaliero.

Stai prevedendo di inserire nelle tabelle (almeno quelle più importatnti) dei campi dove indicare data, ora e utente che ha inserito/modificato/cancellato il record?
Ciao.

Offline Gianluigi

  • Moderatore globale
  • Senatore Gambero
  • *****
  • Post: 4.157
  • Tonno verde
    • Mostra profilo
Re:Sviluppo Gestionale Rubinetto Felice
« Risposta #42 il: 16 Novembre 2015, 18:14:18 »
Scusate ragazzi ma sono due giorni (quasi tre) che mi picchio col sistema operativo (Ubuntu 14.04.3).  :-[
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,
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

@Berserker79,
grazie per avermi ricordato di aggiungere i campi per memorizzare chi effettua cosa. Ho preso nota e ne riparliamo quando inizieremo a discutere dei campi delle tabelle.  :ok:

In questi giorni insieme allo studio di PostgreSQL vorrei che iniziassimo a mettere giù il protocollo per la standardizzazione dei termini, purtroppo è chiaro che ognuno di noi ha una sua idea diversa 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.
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?
Grazie
 :ciao:
nuoto in attesa del bacio di una principessa che mi trasformi in un gambero azzurro

Offline sotema

  • Maestro Gambero
  • ****
  • Post: 467
    • Mostra profilo
Re:Sviluppo Gestionale Rubinetto Felice
« Risposta #43 il: 16 Novembre 2015, 22:16:04 »
Scusate ragazzi ma sono due giorni (quasi tre) che mi picchio col sistema operativo (Ubuntu 14.04.3).  :-[
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.
Sbagliando si impara... ;D

@Sotema,
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
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.

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.
Sotema hai parlato anche di standardizzazione della struttura cosa intendevi esattamente?
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.

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?
Grazie
 :ciao:
Ora vado a rileggerlo.
L'uomo ha inventato la bomba atomica, ma nessun topo al mondo costruirebbe una trappola per topi.
Albert Einstein

Offline Gianluigi

  • Moderatore globale
  • Senatore Gambero
  • *****
  • Post: 4.157
  • Tonno verde
    • Mostra profilo
Re:Sviluppo Gestionale Rubinetto Felice
« Risposta #44 il: 17 Novembre 2015, 22:33:36 »
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.

Ciao Sotema,
Io avevo scritto questo in una domanda a Berserker79
Citazione da: Gianluigi
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.

Vedo che tu usi per le tabelle nomi singolari ma su questo non sarei d'accordo essendo la tabella un insieme di tanti campi mi appare cosa più intuitiva utilizzare per le tabelle il plurale e per il campo il singolare. Se però ti comporta problemi dillo pure.

Ricapitoliamo:
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.
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 &= ";"

Forse ci sarebbe da parlare di altro ancora, ho un po guardato in giro ma sono troppo poco pratico di  database tosti e non, ho visto che tanti inseriscono nel nome anche PK FK TRG ecc.
A me non pare il caso, forse si potrebbe fare un'eccezione per i campi indicizzati, cosa ne pensate?

Scusate ragazzi se vi appaio un po svuotato, ma i fatti di Parigi...
nuoto in attesa del bacio di una principessa che mi trasformi in un gambero azzurro