I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.
16 messaggi this document does not accept new posts
gufo_rosso Di gufo_rosso postato il 11/04/2008 08:17
la cosa di usare id autoincrement (usato dal db ssn usa) non e' quello
di garantire unicita del dato ma la sua rapida elaborazione (il ssn italiano soffre dei problemi da te descritti "duplicazione"),
gli id sono di piu facile gestione e passaggio di variabili da php
Dissento. Il linguaggio di programmazione o il programma se ne fregano di quanto sono lunghe le chiavi, se parliamo di programmatore pigro e' un altro discorso
Non permettono la modifica (ovvero NON vanno modificati) se cancelli il record.
Le chiavi primarie non vanno mai modificate a prescindere da come sono fatte. Se hai un sistema che lo consente il sistema e' bacato.
le relazioni a me sembrano piu facili
a te. a me no
il contro se devi recuprare una relazioni devi fare join (o theta)
anche solo per un valore, se parlimo di clienti il campo univoco e' PIVA o CF
il CF non e', non e' mai stato e mai sara' un valore univoco
in caso di un magazzino hai il codice (che puo essere inventato da user, o autogenerato).
un contro e' la dimensione degli indici su numero di record alto
E chi se ne... della dimensione degli indici? Quello fa parte delle specifiche del software, inoltre, con i dischi fissi attuali, hai voglia a fare indici...
Luca Di Luca postato il 16/08/2008 08:39
Perche' non lo e', visto che puo' essere "calcolato" al momento. Il fatto che contenga il nome, cognome data e luogo di nascita della persona, non ne fa un buon candidato. In una citta' di una certa dimensione, ci sono troppe possibilita' che due persone con nome sufficientemente simile siano nate nello stesso giorno. Ceeeerto, puoi chiedere al ministero e yada yada yada... ma guardiamo in faccia la realta': chi lo fa?
Lex Di Lex postato il 24/08/2008 13:30
P.S.
Naturalmente la progettazione è stata fatta con gli ID autogenerati (almeno così ho sentito)
Paolo Brigati Di Paolo Brigati postato il 08/09/2008 12:26
solo un dubbio, per il discorso univocita' cod. fiscale.
A quanto ne so', l'ultimo carattere, il 16° di controllo e' usato anche per evitare doppioni, venendo cambiato in caso un C.F. identico esista gia' rispetto a quello in emissione....o sbaglio?
il fatto che il CF possa essere auto-calcolato e che le uniche informazioni che contiene siano il nome, cognome, data e luogo di nascita ne fanno, per definizione, un codice NON-univoco. Puo' darsi che, se tu informi l'ufficio competente, quelli possano cambiarlo, ma per informare l'ufficio, devi sapere che il codice e' non-univoco. Se il codice fosse progettato per essere univico, non potresti autocalcolarlo. Quindi assumere che tale codice sia univoco e' sempre e comunque un errore
Davide Di Davide postato il 12/09/2008 08:30
In merito a chiavi composte da più campi, devo però aggiungere che lavorando con strumenti tipo Object/Relational mapping, la cruda realtà è che se vuoi tenerti le chiavi naturali (o business key, che fà più figo) devi faticare molto di più e alcune funzionalità ti sono precluse se non hai oggetti con un solo campo come chiave.
Questa cosa mi fa pensare che chi scrive questi ORM è bravissimo nella programmazione ma ha un'idea di database un po' particolare.
il che mi fa pensare che usare tali strumenti dovrebbe venire per secondo, e come prima cosa dovrebbe esserci usare la propria testa.
Davide Di Davide postato il 12/09/2008 10:27
Concordo, e chiaramente ognuno ha le proprie esperienze e le proprie preferenze sugli strumenti da usare.
Personalmente, su applicativi di dimesioni medio grandi e con logiche un po' complesse ho visto ridursi e semplificarsi parecchio il mio codice (utilizzo in larga parte Java e lo strumento di cui parlo è Hibernate).
Antonio Di Antonio postato il 23/09/2008 14:09
Anch'io avrei da dissentire riguardo al CF.
D'accordo che non sia affidabile considerarlo univoco, de facto, ma solo perché viene "usato" male. Mi spiego, altrimenti sembra che stia dicendo idiozie.
Sono quasi sicuro (al 99%, mi ri-documenterò) che SIA univoco, che solo l'Agenzia delle Entrate possa emanarlo, al che segue automaticamente che NON sia possibile autocalcolarlo. Chi lo fa commette un abuso, proprio perché il calcolo ti dà solo una "discreta" probabilità di avere un CF esatto. Lo sarà nella maggioranza dei casi. Ma quello esatto è proprio quello calcolato ed eventualmente corretto per evitare duplicazioni.
Rimane che "di fatto" è meglio non usarlo, perché nemmeno le autorità competenti riescono a controllare i casi di duplicazione.
Gabriele Paggi Di Gabriele Paggi postato il 09/10/2008 11:25
@ Gabriele Paggi Di Diegoepoimaria postato il 24/09/2012 12:16
Mio padre spesso racconta che, da giovane neolaureato, lavorò per qualche anno in una ditta chiamata Sogei, come programmatore, e li conobbe l'ideatore del codice fiscale, e spesso ne elogia i meriti e ne racconta le vicissitudini.
Il codice fiscale è univoco poichè è emesso , come hanno già detto, solo e soltanto dall'Agenzia delle Entrate.
Il motivo per cui fu scelto è che si voleva un codice che avesse una qualche attinenza con la realtà, e che potesse ricordare il nome della perosna interessata ... grave errore ...
Se si fosse scelto un codice NON ricostruibile, nessuno avrebbe pensato di crearselo da solo in caso di smarrimento del tesserino, e ne tantomeno ci sarebbero siti che "tentano" di calcolarlo, con metodi che possono anche ssere giusti, am che mancano dell'unico e fondamentale controllo: l' unicità.
In teoria è quindi giusto usare il codice fiscale, ma, in pratica, dal momento che esso viene inserito da utonti senza la minima cognizione di causa ( e senza la possibiltià alcuna di controllo sulla esattezza del codice, dato che l'Agenzia delle Entrate può modificare, cioè "sbagliare" ad hoc il codice ), concordo sul fatto che non sia giusto usarlo come chiave primaria.
Per inciso: Ora capisco tutta la rottura di scatole di codice che il mio capo schiavista mi stà facendo scrivere per la gestione del DB ... 
crwn Di crwn postato il 22/12/2008 14:08
Il tutto è contenuto in qualche file excel o txt che dovrebbe essere reperibile in qualche sito di qualche ministero....
Con tutti questi condizionali avete già capito che problemi comporta gestire il tutto....
Di Anonymous coward postato il 29/01/2011 23:21
Se alla chiave primaria autogenerata si aggiunge una chiave univoca gestita dagli utonti (per capirci: quella che essi vedono ed usano per identificare l'elemento della tabella) si hanno a mio modo di vedere notevoli vantaggi, per esempio quello di poter adottare un criterio di codifica della chiave unica e poi avere un ripensamento senza per questo dover metter mano alla rifasatura delle dipendenze. Un esempio per chiarire: nel db ho i prodotti e le righe delle spedizioni dei medesimi; se la riga della spedizione fa riferimento al prodotto attraverso la chiave autogenerata, posso cambiare a piacimento il codice esterno (la chiave univoca) del prodotto senza perdere la relazione con le spedizioni avvenute.
@ Anonymous coward Di Davide Bianchi postato il 30/01/2011 09:57
posso cambiare a piacimento il codice esterno
Questo puzza di cattiva progettazione/analisi lontano un kilometro. Perche' dovresti voler cambiare il codice esterno?
-- Davide Bianchi
Di Massimo M. postato il 24/09/2012 21:33
Io nei miei db ho sempre usato una pk autoincrementante, usando poi, se necessario, le chiavi composte dai campi.
Per un semplice motivo: ho una tabella padre e una figlia, perche' nei programmi dovrei scrivere "select from figlia where campo1=pippo and campo2=pluto and campo3=paperino and....."
quando posso scrivere
select from figlia where idpadre=2?
una semplice pk autogenerata mi porta via pochissimo spazio, non e' pesante, non mi limita nell'avere chiavi composte da campi, e mi permette di accorciare le select e di non dovermi ricordare "la pk del padre e' codicearticolo+taglia+colore o codicearticolo+taglia+colore+ordine o ...."
per quanto riguarda il "una pk non puo' essere mai cambiata", beh, si quella e' la teoria, in pratica ho assistito a parecchi cambi di pk, del tipo da "codice+taglia" a "codice+taglia+colore". Vero, e' stato mal progettato dall'inizio, cio' non toglie che succeda.
-- Massimo M.
@ Massimo M. Di Davide Bianchi postato il 25/09/2012 14:52
perche' nei programmi dovrei scrivere
Per lo stesso motivo per cui si usano variabili dal nome diverso da 'a' e 'b' e 'c'. Perche' IL CODICE DIVENTA PIU' LEGGIBILE e FACILMENTE MANTENIBILE! Perche' poi quando vai a rivedere la struttura capisci al volo cosa lega tabbela 'a' alla tabella 'b' (ed a tutte le altre).
-- Davide Bianchi
Di lufo88 postato il 15/05/2013 20:06
Parlando di MySQL mi hanno spiegato che c'è un motivo per usare gli id autoincrementali (e usare UNIQUE su altri campi). A quanto pare essendo MySQL quello che è (una mezza fetecchia) Se gli aggiungi record con un ID autoincrementale come PK non deve rigenerare d'accapo l'indice sulla PK (cosa non vera con PK più "sensate").
-- lufo88
Di Rigongia postato il 08/03/2014 22:18
Solo una annotazione sul presunto contro del "se cambio la PK si scassa tutto" : anche su quella mezza fetecchia di MySQL esiste (quindi do per scontato che esista anche su sistemi un pelo piu' tosti) la possibilita' quando si definisce una chiave esterna di specificare cosa fare in caso di update o delete dei campi a cui quella chiave si riferisce. Ergo se cambio il valore della PK si smazza in automatico il DBMS ...
-- Rigongia
