Newsgroup: it.comp.software.database
Titolo: E-commerce - normalizzazione o ridondanza

Ciao a tutti.
Vorrei sottoporre un quesito nell'intento di sentire le Vs. opinioni.
Sto sviluppando un sistema e-commerce e sono quasi giunto alla chiusura
degli ordini, che rappresenta un punto caldo al fine di normalizzare il
DB.
L'idea è la seguente:
1. creare una tabella "ORDINI", con Primary Key sull'ID univico
dell'ordine. Un campo "ID cliente" in relazione con la tabella clienti
e ulteriori campi contenti informazioni come data dell'ordine, stato,
ecc.
2. creare una tabella "ORDINI_PRODOTTO" da mettere in relazione con
quella di cui sopra dove elencare i prodotti acquistati in base al
numero ordine.
3. direi che un bel vincolo referenziale tra le due tabelle è d'uopo
per salvaguardare la consistenza dei dati :)
Ora veniamo alla domanda.
Ammettiamo che l'amministratore dello Shopping System voglia eliminare
un cliente. Ma potremmo fare analogo con l'eliminazione di un prodotto.
Se voglio mantenere consistenza nei dati devo elimanare anche i record
a lui associati nella tabella "ORDINI", che tra le altre cose è legata
da un vincolo alla tabella "ORDINI_PRODOTTO".
Ok...così facendo si salvaguardia consistenza e normalizzazione del
DB, ma d'altra parte si perdono importanti informazioni che aiutano a
creare statistiche e mille altre cose.
Una possibile soluzione potrebbe essere quella di indicare i nomi dei
clienti nella tabella "ORDINI" piuttosto che l'ID cliente, e i nomi
prodotto nella tabella "ORDINI_PRODOTTO" piuttosto che l'ID prodotto,
ma così facendo si creerebbe un bel po di ridondanza nei dati.
Oppure si potrebbe usare una ulteriore tabella come storico, ma
probabilmente poi l'affare si complicherebbe e non credo che si
risolverebbe il problema della ridondanza.
L'ultima soluzione che ho valutato e quella di non eliminare ne clienti
ne prodotti, ma contrassegnarli
come "NON ATTIVI". Questa sarebbe tutto sommato veloce e richiederebbe
la presenza di un ulteriore campo di controllo.
Insomma sono sicuro che le strade percorribili sono diverse e che non
esiste una risposta precisa.
Per questo chiedo qualche idea / critica / proposta :)
Ciao a tutti e grazie.
Giuseppe

 Giuseppe
ciao

 Per questo chiedo qualche idea / critica / proposta :)
Certo che esiste una risposta precisa, ed è pure la più difficile...
Siccome ho due orologi, ed ogni tanto guardo quell'altro, può
capitare che anche io NON scelga la numero 4 ;-)
bye

 capitare che anche io NON scelga la numero 4 ;-)
Afferrato il concetto,e credo di essere d'accordo con te.
Direi che una volta analizzata la situazione potrei preferire la prima
o la seconda delle ipotesi da te segnalate.
Molte grazie per l'interessemento.
Giuseppe

 a livello legale non va bene perché i dati ci sono comunque...
ok sull'azzerare dall'anagrafica un nome che non ha legate transazioni.
ma se sono un isp e quello ha navigato (e io devo loggarlo), una banca e lui 
ha prelevato/versato, ecc ecc, in anagrafica spero di poterlo tenere, anche 
se ha chiesto la cancellazione.
seno' e' un bel casino...
grazie e ciao, a. 

Mentre cercavo di capire la differenza tra una select e un drop database,
andrea palazzi ha scritto:

ciao,
la legge sulla privacy ti obbliga a cancellare i dati
quando questi non sono più necessari. Però questo dettame
non può certo sovrapporsi agli altri obblighi legali:
es. se sei un provider DEVI mantenere TUTTI i log sino
al 31-12-2007 (decreto legge anti terrorismo).
Se invece hai il consenso del proprietario dei dati, puoi
tenerli indefinitamente (per es. per scopi statistici).
Per questo personalmente sconsiglio vivamente la cancellazione
a favore di un flag attivo/non attivo.
Al limite puoi rinominare il suo id per renderlo nuovamente utilizzabile.
Dove sto io, per es. gli username scaduti/cancellati/revocati ecc, vengono
sostituiti con $_username_$ (che è un valore con caratteri non consentiti
agli utenti normali, ossia quelli che sottoscrivono un servizio) e 
diventano nuovamente fruibili. Ovviamente questo comporta altri problemi,
perchè se _tutto_ non avviene coerentemente si corre il rischio di avere
valori duplicati o situazioni sporche.
ciao


http://csvtosql.sf.net
Milano, come Torino, Venezia, Roma, vive in prima persona il problema della
Cocaina. Non se ne trova abbastanza.

"andrea":

Per i dettagli legali, vale a dire quando esattamente si applica
tale norma, rimando ad un consulente, a cui non intendo sostituirmi.
Dal punto di vista tecnico, io mi preoccupo di come implementare
la norma che recita:
"3. L'interessato ha diritto di ottenere:
a) l'aggiornamento, la rettificazione ovvero, quando vi ha interesse,
l'integrazione dei dati;
b) la cancellazione, la trasformazione in forma anonima o il blocco
dei dati trattati in violazione di legge, compresi quelli di cui non
è necessaria la conservazione in relazione agli scopi per i quali i
dati sono stati raccolti o successivamente trattati"
Se tu hai una tabella tipo:
Clienti { CF, Nome, Cognome, OrientamentoSessuale, Cancellato }
e quel Cancellato lo setti a true, se tu fai un select * i dati
saltano fuori comunque! Vorrei poi vedere come lo spieghi ai
signori in divisa che i dati in realtà "sarebbero" cancellati per
cui è "come se" non ci fossero...

 cui è "come se" non ci fossero...
ma la select la farei, nel caso, where deleted=false...
d'altra parte, ai signori non vorrei spiegare che non so piu' chi e' che ha 
consultato 
alqaeda.org
 e poi ha chiesto di essere rimosso...
ciao, a.

 quando questi non sono più necessari.
appunto. se sono necessari non se ne parla proprio.
ciao, a.

 
Innanzitutto per mantenere uno storico probabilmente non ti serve sapere
tutti i dettagli di un cliente.
Io quindi creerei una tabella Clienti, con un id non 'reale', in cui
metterei solo le informazioni che ti servono per le statistiche, come
sesso, provincia etc.
Poi creerei una tabella InfoClienti, con magari un id 'reale' (codice
fiscale?) e le varie informazioni sensibili.
Quindi una tabella:
CREATE TABLE IDClienti (
	id_cliente INTEGER REFERENCES Clienti(id_cliente),
  	id_info_cliente INTEGER REFERENCES InfoClienti(id_info_cliente)
);
In questo modo devi solo cancellare la riga in InfoClienti.
Il tutto non testato.
P.S.
Con le foreign key puoi anche fare ON DELETE SET NULL, usando la
soluzione piů semplice.
In quest modo anche se cancelli un utente, mantieni comunque lo storico
degli ordini.
Saluti  Manlio Perillo

 ma la select la farei, nel caso, where deleted=false...
...occultando quindi volontariamente alle forze dell'ordine una parte
dei dati.
Ti consiglio vivamente di stampare questo messaggio e di farlo
vedere al vostro consulente per la privacy.

 vedere al vostro consulente per la privacy.
lo faro'.
a parte questo, temo di non aver capito cosa intendi.
le forze dell'ordine si prendono il db intero, e ci fanno le query che 
vogliono. da quel punto di vista, fine del discorso, i flag che metto sono 
ininteressanti.
per il resto, il deleted=false serve a me per non eliminare realmente i dati 
di qualcuno che ha effettuato transazioni e al tempo stesso non farli 
apparire dove non e' il caso.
sono un isp? quanto devo tenere il log? due anni? in quei due anni, azzero 
il n. 
c.id
. dell'op, e qualche problema con le forze dell'ordine potrei 
averlo davvero. idem per un riciclaggio, se sono una banca.
oppure non ho proprio capito come tu gestisci questo tipo di problemi.
ciao, a.