Newsgroup: it.comp.software.database
Titolo: duplicati in mysql

SELECT *,count(*) FROM user_user group by ut_nome, ut_cognom, ut_codfis
HAVING count(*) > 1 LIMIT 0,15;
pero io voglio il 2° inserito non il primo cioe mi interessa il piu
recente inserito duplicato

 recente inserito duplicato
Parti a leggere dalla fine dell'archivio.
Alla prossima.
	MAX

 ha scritto nel messaggio
news:f9vhbj$efo$1...@news2.task.gda.pl...

non sono mica tanto sicuro che l'ultimo che trovi sia il più recente.
in access per esempio se tu cancelli un record da una tabella , poniamo il
terzo di 10, e poi ne inserisci uno nuovo, quello può benissimo infilarsi al
posto di quello cancellato e diventare il nuovo terzo (questo se gli gira, a
volte lo fa a volte no, te lo dico per esperienza).
non so come funzioni mysql, ma io non correrei il rischio , tanto più se è
stato fatto un optimize alla tabella o un create table pippo select * from
pluto.
l'unica soluzione sicura è fare il max della data (se c'è la data
ovviamente, se no soccazzi) o per lo meno di un campo incrementale (se c'è
se no soccazzi)

 
Tutto dipende dalla chiave primaria.
Se il DB e' strutturato correttamente non hai (dovresti avere) la 
possibilita' di inserire duplicati.
Alla prossima.
          MAX

 
Sia la data che il campo autonum non risolvono il problema, anzi possono 
crearne degli altri.
Alla prossima.
	MAX

massimo61 ha scritto:

sai tutti ti danno il codice fiscale, data di nascita ecc....
mario rossi come fai a non inserirlo 2 volte ?
dove si ha la correttezza dei dati non e' possibile inserire duplicati
ci vorrebbe qualcosa che possa controllare l'inserimento dei dati
tentando un check sui dati gia esistenti
(l'applicazione e' web non java, o esegubile)

 dove si ha la correttezza dei dati non e' possibile inserire duplicati
Il ragionamento va fatto all'inverso.
bye 

 
per corretteza intendo un codice prodotto, un fabricante
un codice di costruzione (cioe un dato unico indispensabile ai dati)
in un anagrafica (non fiscale) l'univocita va a farsi friggere
visto che mail,nome cognome non sono affidabili


 puo portare a licenziamento, annullamento di un contratto, sanzioni ?)
Dipende da tante cose; in primis da quale contratto hai con il
committente, quanto sono dettagliate le specifiche, quanta
responsabilita' e' effettivamente imputabile a te etc...
Se sei un semplice dipendente, mi sembra che la sanzione per te
in caso di _negligenza_ (quindi non una semplice svista) non puo'
superare l'importo di alcune ore di lavoro.
Tante sono le considerazioni da fare, e i trucchi da iena esistono
da ambo le parti... ho personalmente visto il cecchinaggio di
un progetto con lo scopo di non pagare un anno di lavoro, anzi
con addirittura la minaccia di addebitare i danni di mancata
consegna entro i termini previsti.
Per giustificarsi almeno parzialmente, il "project manager" ha a
sua volta scaricato la responsabilita' sul programmatore.
Raccomandasi mutande di ferro; non solo in questo caso, proprio
per prassi.
bye 

 mario rossi come fai a non inserirlo 2 volte ?
Perdonami ma non comprendo dove possa essere il problema. Se rendi 
chiave primaria ad esempio il "codice fiscale" poi basta che ti gestisci 
l'errore di chiave duplicata che Mysql ti restituisci in caso di 
inserimento duplicato (e di solito sui dati anagrafici di persona fisica 
si fa così). Prima di inserirlo però fai un controllo con una delle 1000 
funzioni che trovi su internet se il codice fiscale è esatto. Se ti 
trovi di fronte a una società devi prevedere la possibilità che questa 
non abbia il CF o non possa inserirlo ma almeno inserisca la partita 
IVA. In ogni caso puoi rendere chiave primaria entrambi i campi (avendo 
lunghezze diverse e codici diversi non ti consiglio di salvare tutto 
nello stesso campo). In modo da non avere 2 tabelle molto simili. Tanto 
al massimo hai il CF e non la PIVA (cerca un simbolo generico da 
inserire nel campo della PIVA visto che il campo chiave non può essere 
vuoto).
Poi come detto mysql sputa fuori sulla pagina web l'errore, te lo 
gestisci, e restituisci al client che ha tentato l'inserimento una frase 
del tipo "Dato già presente".
Fare chiave il nome e cognome, ihmo, è molto rischioso. Può 
tranquillamente esistere un omonimo e il tuo prog risulterebbe bloccato 
e il committente potrebbe adirarsi. Inoltre la modifica a posteriori del 
DB oltre a essere sconsigliata è anche una pecionata.
Ciao.

 Ciao.

 questa "eccezzione" ?
Il che dimostrebbe cosa? Una procedura applicata in modo errato
non implica che la stessa sia errata...
[Quoto]
"Ecco l'elenco delle sorprese. Fotocopie dei codici fiscali:
Vignali ne ha due.
E' possibile avere due codici? e' la domanda ad un funzionario
dell'agenzia delle Entrate: «Siamo matti», voce scandalizzata."
-----
Piccola digressione: vedo talvolta citare il fatto che una persona
abbia due codici fiscali (o argomento simile) per dimostrare
che il codice fiscale non possa essere una chiave primaria; dal
punto di vista strettamente del data modeling questo argomento
NON e' valido.
Se dico che Codice Fiscale identifica una Persona in ruolo di chiave
primaria, intendo dire che dal CF ho una dipendenza funzionale tale
che:
CF -> P un codice fiscale identifica una e una sola persona
Essendo interpretabile come una funzione, tutti sappiamo che
f(CF) = P, NON implica l'inverso, ossia che f(P) = CF
Pertanto da CF -> P   NON posso dedurre   P -> CF.
Il discorso sarebbe valido se si realizzasse una corrispondenza
biunivoca tra gli insiemi dei valori di CF e di P, tale che
CF <-> P
ad ogni valore di cf corrisponde una e solo una persona, e viceversa.
Ma la corrispondenza biunivoca non e' un requisito per una chiave
primaria! Per fare un semplice esempio restando in tema, si supponga
una tabella di ditte di artigiani; una Partita Iva e' posseduta
da uno e solo un artigiano, eppure sicuramente non possiamo impedire
ad una persona di avere piu' di una ditta! Per cui:
Artigiani
---------
PI1 Art1
PI2 Art2
PI3 Art1  -> la persona Art1 ha due partite iva
Noi possiamo sicuramente dire che Partita Iva e' una chiave
primaria adeguata per la tabella, dato che
PI -> Art ogni partita iva e' posseduta da uno e un solo Artigiano
ma l'inverso Art -> PI non e' valido dato che un artigiano puo'
aprirsi quante ditte vuole.
Nel caso sopra c'e' una dipendenza multivalore (MVD) per cui il
discorso sarebbe semmai
Art ->> PI
ossia un singolo artigiano ha un gruppo distinto di partite iva
ascrivibili unicamente a lui.
Il punto focale e' che CF -> P anche se una persona ha piu' di
un CF, dato che il codice fiscale continuerebbe COMUNQUE a
identificare una e una sola persona! Il patatrak si avrebbe se lo
stesso codice fiscale identificasse due persone DIVERSE.
Ricapitolando, la corrispondenza biunivoca e' certamente
desiderabile in alcuni casi pratici, ma la sua assenza non la
squalifica automaticamente dall'essere chiave primaria dal punto
di vista del DB.
bye 

PS: adesso avremo tutti quanti una chiave primaria nuova di stecca:
il SSN; io non l'ho ancora esaminata (vedremo se gli uffici
pubblici faranno casino anche con questa...)

 
il SSN == codice fiscale
comunque fanno casino con tutto

 comunque fanno casino con tutto
In linea di massima anche il CF non è sempre esatto... esistono dei casi 
in cui persone che potevano avere lo stesso CF hanno invece avuto 2 
codici diversi. Questo significa che mentre per uno tutti i sistemi per 
generare CF funzionano, per l'altro non vanno bene. Inoltre, quando 
capita di fare una tabella dei contatti di solito il CF me lo autogenero 
e lo tengo nascosto. Nel caso dovessi avere 2 CF uguali genero errore di 
duplicato e obbligo il client (se autorizzato) a forzare la procedura 
inserendo nel CF un carattere progressivo come "-01" (di solito il CF 
finisce con "-00"). E' per me impossibile pensare di avere più di 2 con 
lo stesso CF ma non si sa mai percui ne prevedo un max di 99 :)
Il CF per me è solo un codice come tanti. Ma è univoco sicuramente. E' 
anche vero però che l'utente che inserisce deve almeno inserire i campi 
che mi servono per generarlo. Fino ad ora ho sempre avuto contatti 
ordinati e disposti a compilare quei pochi campi obbl. La P.IVA non l'ho 
mai messo come campo obbl. ma in caso di società, questa è obbligata a 
inserirla.
Cmq perchè non puoi inserire tutto in una stessa tabella? Basta inserire 
un campo numerico tipo "idAzienda" dove metti l'id della società di cui 
fa parte la persona. no?

 comunque fanno casino con tutto
Conto il tempo che manca ad uno scambio di persona...
Non oso pensare cosa succederebbe. Uno potrebbe ritrovarsi le
patologie di un'altra persona; o le cure verranno somministrate
al paziente sbagliato.
Curiosita': mentre scrivo questo (19:20), il tg3 da' la notizia
che la polizia di frontiera ha bloccato un presunto terrorista,
dato che il database lo identificava come tale basandosi sul
NOME e COGNOME (wow che tecnologia); peccato la persona fosse...
un bambino di 8 anni! Eppure tanto e' bastato a far scattare le
misure antiterroristiche!
La perla finale del servizio riporta che "bisognerebbe includere
anche l'anno di nascita" per evitare tali problemi. Che geni.

 inserire i campi che mi servono per generarlo.
Secondo me stai sbagliando.
Oltre a quanto ho detto sopra, so per conoscenza diretta di un
caso in cui non e' possibile calcolarsi il CF a partire dai dati,
in quanto risulterebbe in ogni caso errato.
Si tratta di un errore di emissione da parte dell'anagrafe
tributaria, che anche se palese, non ha ritenuto necessario
correggerlo (il CF serve comunque al suo scopo).
bye

 
toriamo ai db che e' meglio

aaa ha scritto:

l'azienda non e utente

Ma al giorno d'oggi, che stanno ristampando i cartellini sanitari, non 
era meglio trovare un sistema europeo univoco, sicuramente più evoluto 
del CF, che mi attribuisse un codice univoco almeno in Europa?
Possibile che in frontiera stanno ancora al "Nome e Cognome"? ma almeno 
al CF ci sono arrivati?
Bah...

Mi ripeto... Per me il codice generato è solo un codice SICURAMENTE 
univoco. Mi spieghi che cos'altro vai a controllare su una persona fisica?
Bloccare l'inserimeno per "Nome e Cognome" è un errore, inserire 
comunque è una possibile duplicazione di contatto, inserire un controllo 
sul domicilio è un errore perchè ci possono essere più contatti sul 
domicilio... non ti piace che io sfrutti un codice di facile 
generazione? Allora sfrutta la funzione che ti pare per crearti il 
codice. Come ho detto per me il codice generato è solo una stringa 
univoca. Il campo del CF è un altro campo... che se l'utente inserisce o 
meno a me cambia poco... L'unica cosa che faccio se me lo inserisce è 
che una volta testata la veridicità del CF inserito, lo sostituisco al 
codice della mia chiave. Ma x il resto la mia è sicuramente una chiave 
univoca che permette il test anche a posteriori. :)
no? Ehi commentate che io evolvo :oP

 no? Ehi commentate che io evolvo :oP
E' sicuramente interessante la post verifica, ed io tendo a
preferire le chiavi "parlanti".
Ma a questo punto perche' scegliere un pseudo CF che va a
sovrapporsi al vero CF, col rischio di fare confusione?
bye 

 bye 
:) Ciao.

 non ci si sbaglia.
Gia', ma tu presumi che i dati vengano inseriti da un operatore
che verifica i dati preesistenti e fa una scelta giusta.
Questo non e' mica detto che accada; il caso sempre piu' frequente
con l'informatizzazione e' di server che si scambiano dati in
maniera automatizzata.
bye bye