Newsgroup: it.comp.lang.visual-basic
Titolo: integrità referenziale non serve...

salve a tutti,
qualche giorno fa mi sono imbattuto in un ragionamento da programmatori la
cui concluisione è: l'integrità referenziale in un db è meglio non usarla.
Quando me l'hanno detto pensavo: "Ma forse ha ragione".... ma non ne sono
poi così convinto, anzi pensadonci meglio non ne sono convinto affatto.
In sintesi questo è il ragionamento che ha portato a queste conclusioni:
Mi è stato detto che per fare un software complicato l'integrità
referenziale non si può usare perchè comunque viene tutto gestito dalla
logica del software stesso (a detta loro tramite le listview) (?!?) e che
nel db le relazioni tra tabelle non vengono messe per far si che l'utente
possa evitare di inserire campi obbligatori.
dato che non credo di essere un super esperto chiedo a voi lumi
grazie
ciao

 possa evitare di inserire campi obbligatori.
Se il campo che non viene inserito è un campo chiave di relazione, e la
relazione è obbligatoria, non vedo perchè debba essere opzionale. Se il
campo è opzionale, non ha niente a che fare con le regole di integrità.
Ciao
Alberto

 wrote in message
news:wv1M8.16133$86.3...@twister1.libero.it...

L'integrità referenziale non c'entra con le listview, né con i campi
obbligatori.
Iniziamo con la definizione: per integrità referenziale si intende
un automatismo insito nei motori di database che permette
di evitare, gestendole, alcune incongruenze che potrebbero
verificarsi fra tabelle relazionate in caso di cancellazione
di righe su una delle tabelle (classico esempio, una tabella
Ordini che contiene i dati di testata degli ordini e una tabella
MovOrd che contiene le righe dei singoli ordini: l'attivazione
dell'integrità referenziale permette di evitare che esistano
Ordini senza neanche una riga di movimenti, né tanto meno
movimenti che non hanno la testata a cui si riferiscono).
Il problema è che esistono diverse modalità di applicazione
dell'integrità referenziale (tra l'altro non tutte implementate
da tutti gli applicativi di database). Alcune di queste, sono
addirittura impossibili da implementare correttamente in
un modello reale.
Di fatto, l'unica integrità che si implementa nella pratica
di tutti i giorni è la cosiddetta "cascade", che consiste
nel cancellare le righe della tabella dipendente quando
vengono cancellate quelle della tabella principale (nell'esempio
di poco fa, se cancello la testata dell'ordine ed è attiva
la modalità "cascade", mi verranno cancellate automaticamente
le righe della tabella MovOrd che si riferiscono a quell'ordine
che ho cancellato).
Personalmente, viste le poche possibilità di implementazione
corretta dell'integrità referenziale, preferisco gestirla
manualmente, aggiungendo un minimo di codice in più,
ma premettendomi una maggiore elasticità nella
manipolazione dei dati.
Nell'esempio precedente, non devo far altro che cancellare
la riga di testata nella tabella Ordini e subito dopo cancellare
nella tabella MovOrd tutte le righe che hanno quel numero di
ordine. (eventualmente, posso mettere il tutto all'interno di
un gruppo Begin Transaction / End Transaction per evitare
che un'interruzione del programma mi lasci il database
incongruente).
--
Er Roscio.

 ha scritto nel messaggio
news:wv1M8.16133$86.3...@twister1.libero.it...

Mai usata, per ridurre al minimo le possibili situazioni "strane" a me non
imputabili (nel senso che non ci posso mettere le mani). Che faccio? Prima
di cancellare un articolo, vado a vedere che non abbia riferimenti da altre
parti, per esempio nei movimenti.

 grazie
grazie a te per il post.. sebbene ti autodefinisci poco esperto,
già il fatto che ti poni domande del genere testimonia a tuo
favore..  risposte a domande del genere non si trovano nè
su Google nè premendo F1, quindi.. ben vengano questo
genere di curiosità..
Ciao
 valter

 all'utilizzo di transazioni, quando è necessario.
4 risposte da persone che rispetto, tutte, in sostanza dello stesso
tenore... dopo lo svarione vbSpace (a prop, pap, non esiste, o il mio vb e'
un tirapacchi) mi tirate un po' su :)
tempo fa c'era stato qui un dibattito ed ero stato abbastanza cazziato
perche' dicevo che dai tempi di db3, e ancora piu' con access, mi fido piu'
della mia logica che di quella del dbms. non so, ho visto troppi ndx
corrompersi solo perche' non ti eri inchinato al punto cardinale giusto
mentre accendevi il pc. con clipper e gli ntx a manina, mai un problema in
anni.
gente che usi in concreto (non a lezione) l'i.r. ancora devo conoscerne.
qualche giorno fa mi dicevano: ma quel db ha circa 1000 tabelle. imho, nasce
maluccio il db. se proprio dev'essere cosi', ok per l'i.r., ma ho come il
sospetto che ci saranno casini in ogni caso...
ciao, a.

 un tirapacchi)
Non esiste nemmeno da me ;-) C'è solo Space(n) o Space$(n)
Forse il Grande Papero ha fatto (a sua volta) confusione con vbKeySpace?
Questo vuol dire che siamo pronti per essere (in 3, almeno) tirati fuori dal
forno?

 della mia logica che di quella del dbms.
Io lo stesso.
Diffido sempre da tutti gli automatismi.
Magari funzionano bene, molto probabilmente meglio del mio codice, ma non ho
alcun controllo su di essi, e se toppano (sai com'è magari oggi un meteorite
passa un po' più vicino a Venere del previsto...) o a me è sfuggita una
virgola dell'help sul loro comportamento sono bello che fregato: dovrei
comunque rivedere tutto cercando dei work-around per problemi non miei.
Tanto vale farmi il mio codice: se è toppato so dove mettere le mani (quasi
sempre nei capelli :P)
Ciao

tutto sta a vedere se colui che scrive codice sa che esiste l'i.r. e lo
utilizza nel codice.
ciao


 Diffido sempre da tutti gli automatismi.
Come detto, anche io non uso mai l'integrità referenziale.
Tuttavia ritengo lo strumento molto utile.
Nella mia società, abbiamo sviluppato un software abbastanza complesso per
la gestione dell'ufficio acquisti di un grosso gruppo industriale, con 19
stabilimenti in Europa.
Ovviamente, un messaggio di errore in un client è tollerato, un dato perso o
danneggiato no.
Per cui, per scrupolo, abbiamo attivato alcune regole di integrità sulle
tabelle principali.
Usiamo SQL2000, e tutte le operazioni sono all'interno di transazioni, per
cui non è la caduta di tensione o il runtime error che ci preoccupa, quanto
la possibilità che una nuova versione di un client possa fare un danno nel
database.
Dopo un paio di mesi dall'avviamento, con il DB già pieno di dati,
installiamo la versione 1234 del software (come ho detto, nei primi mesi la
possibilità che vengano chieste cose non sorte durante l'analisi è
elevatissima). Dopo un paio di giorni, ci chiamano perchè un utente riceve
una segnalazione di errore mentre tenta di fare una determinata operazione.
Cosa era successo? Un bug, di quelli che possono uscire solo dopo che 100
utenti ci lavorano sopra, che chiamava una funzione di cancellazione di dati
con un parametro sbagliato, per cui la funzione cercava di eliminare un
record in relazione con altri.
Grazie alle regole di integrità, SQL server rispondeva picche al comando
SQL.
Intercettando l'errore ADO, veniva segnalato un errore all'utente, ma il
record era salvo.
Risolto il bug, tutto è OK, e soprattutto nessun record è andato perso.
Quando saremo sicuri che non ci sono più questi rischi, toglieremo le regole
di integrità, per aumentare le performance, ma intanto il cliente non avrà
perso neanche un record (sto toccando una vite metallica della
scrivania....)
Ciao
Alberto

 non ho alcun controllo su di essi, e se toppano (sai com'è magari
La potenza è nulla senza il controllo! ;)
Ciao

 tirati fuori dal forno?
Per me, non ne vale la pena. Voi sarete al dente, io ormai
sono stracotto e bruciato...
Bye, G.

 cui concluisione è: l'integrità referenziale in un db è meglio non usarla.
<cut>

 ha scritto
Ciao Andrea. La tua esposizione è pulita, chiara e convincente.
Io, giusto per chiarire il mio atteggiamento, non ho mai pensato, nè detto,
che una tecnologia come quella che tu hai descritto nelle sue
funzionalità/utilità sia sbagliata, logicamente sbagliata. Così come non
dico e non dirò mai che qualsiasi tecnologia possa essere sbagliata. Chi
l'ha inventata (almeno lui, e per me è più che sufficiente) l'ha certamente
ritenuta valida. Quindi, nessuna obiezione a qualsiasi (!)
vecchia/corrente/nuova tecnologia, anzi, tanto di cappello.
Quello che invece penso, e scrivo, è che molto spesso (magari è stato così
in passato e l'esperienza ha dato, allora, alcuni insegnamenti ormai
assimilati e forse non più veri) l'una o l'altra tecnologia non funziona,
non funziona sempre e/o può creare problemi.
Come ho già avuto occasione di dire, personalmente cerco di usare il meno
possibile di quanto pure avrei liberamente a disposizione, solo ed
esclusivamente per ridurre i potenziali problemi che possano nascere da
qualcosa in cui io (che alla fine sono quello che deve risolvere il
pasticcio) NON posso mettere le mani.
E, in tanti anni, Microsoft mi ha insegnato di non fidarmi troppo di lei e
dei suoi strumenti. Quindi, meno ne uso, meno problemi avrò. Questo volevo
dire, ma, senza alcun problema, rialzo sinceramente il cappello a chi quella
tecnologia ha inventato.
Ammiro la teoria, ho il terrore di metterla in pratica. Ciao.

 possa evitare di inserire campi obbligatori.
esisto no vincoli di integrita'  0 a N
Inoltre l'integrita' referenziale velocizza le ricerche, poiche' un vincolo
su una foreign key e' + veloce di iun indice sui due campi
che poi i programmi funzionino lo stesso, e possano essere validi lo stesso
questo va e' vero.
Pero' pensiamo a quando un DB fatto da noi viene usato da programmi non
fatti da noi, ma da terze parti, con L'IR ho la garanzia
che l'altro programma sottosta' alle regole per un corretto uso del
programma.
ciao benny

chiaramente, my $0.02
Senza fattura, quanto ci fai di sconto? :P
-- 
ciao, hal

Senza fattura, quanto ci fai di sconto? :P
niente sconto, il $ sta anche calando!!!! e poi oggi l'Italia ha perso...


 ha scritto
Ora un po' di cose si chiariscono. Lo dico senza polemica.
L'unica volta che ho avuto il tempo (letteralmente) di lavorare in team a
progettare un lavoro ipotetico (Min.Giustizia, Meccanizzazione del sistema
penitenziario italiano), non mi sono nemmeno divertito. Non tanto perchè poi
non sono stato pagato dal mio "appaltatore", quanto perchè avevo la
sensazione di "perdere tempo". Corso su Bachman e uso dello stesso per fare
un sacco di belle figurine e relazioni 1:N, N:N, N:1 fra di loro. Visite di
alcune ore presso 3/4 carceri campione e stesura dell'analisi con licenza di
inventiva. Riepilogo in sede e progettazione. Vi dirò, non fa per me!
La mia realtà quotidiana è questa:
Un cliente che sta lavorando con soddisfazione da tempo chiede: "Le
provvigioni dei miei agenti sono a scaglioni di valore sulla differenza fra
il prezzo di vendita e il costo, catalogate e separate per famiglia di
articoli con qualche eccezione per la merce che vendiamo di più. Ogni punto
di sconto contempla una "penale" sulla percentuale di provvigione di quello
scaglione. Gli scaglioni sono anche differenti in funzione della dilazione
di pagamento per ogni fattura." E conclude con: "Sono stufo di fare 'sti
difficili calcoli a mano, sbaglio sempre e impiego un sacco di tempo. Me le
fai tu, per dopodomani che devo fatturare qualche milione di euro? Ci conto,
eh!".
Io, in qualche ora devo fare tutto questo e, credetemi, non ho il tempo di
fare studi sul database e sulle relazioni fra la decina di tabelle
interessate. Spendo un'ora per sapere dove devo andare a parare e butto giù
tre sghiribizzi su di un pezzo di carta e poi comincio a fare le modifiche.
Pensate voi se dovessi anche essere limitato e/o rivedere le imposizioni
strutturali del database che potevano essere perfette fino a 10 minuti prima
e inevitabilmente destinate a cambiare alla prossima telefonata.
Infatti:
"Oh, qui non va bene niente! Quando faccio la bolla a quel cliente il prezzo
che mi deve essere proposto è quello della bolla precedente per gli articoli
composti, invece quello normale per gli articoli che compro e quello medio
maggiorato di quel che dico io per quelli che produco. Per l'altro cliente
invece è simile, ma è un po' al contrario. Beh, mi sono spiegato, vero?
Fallo alla svelta che sennò m'incazzo."
Io, sinceramente, vi apprezzo e stimo, ma non vi invidio, nè, altrettanto
sinceramente, farei cambio di lavoro. Mi tengo i miei clienti che mi fanno
dannare e che, ogni tanto, mi dicono "oh, bravo, è quello che ti ho
chiesto", piuttosto di morire in riunioni fiume dove si decide tutto come se
fosse l'ultima e migliore architettura per quel progetto. Inamovibile e
perfetta, funziona persino nella fase di test e basta guardarla per esserne
soddisfatti. Poi il capo commessa cambia una virgola nel conteggio di alcune
statistiche decennali e dovete rivedere il tutto a partire dal primo schema,
quello che rappresenza le procedure da attivare allo squillo del telefono di
un potenziale cliente che vuole un preventivo. Lasciamo stare il cliente
finale che forse avrà la sensazione di aver speso bene i suoi soldi con
tutta quella perfetta documentazione di analisi, ma, dopo 6 mesi/1 anno,
forse, chiama me per ... quel discorso sulle provvigioni o perchè il
Ministero ha deciso che l'IVA sulle vendite di tipo agricolo all'estero non
sia più integralmente scorporabile, ma solo a concorrenza del totale degli
acquisti per una percentuale assolutamente cervellotica relativamente
all'aliquota IVA originaria del bene.
Ragà, a ciascuno il suo e, come vien da dire, "l'erba del vicino è sempre
più verde". Sarà vero? Sarà falso?
Chiediamolo al cliente che chiamerà domani.

 su una foreign key e' + veloce di iun indice sui due campi
Queste sono le solite balle spaziali che raccontano
i venditori di sistemi CASE...
Personalmente, lo devo ancora scoprire un motore
che fa davvero quello che dice di fare, e che non
si pianta con un paio di subselect del cavolo,
che non siano "pensate" apposta per farlo girare
velocemente...
La verità è che per ottenere il massimo da un motore,
devi conoscere a fondo le sue regole, cosa che non
succede quasi mai, in quanto le case di softrware
sono molto gelose dei loro prodotti e non ti danno
quasi mai un appoggio così approfondito (salvo
rarissime eccezioni).
--
Er Roscio.

 siamo sicuramente in un terreno di guerre religiose....
Quello che dici tu è valido, ma solo in teoria o, al massimo,
in sistemi altamente professionali e integrati, ma non certo
SqlServer o addirittura in Access...
A parte il fatto che una normalizzazione troppo spinta
(già oltre la terza f.n.) è quasi sempre deleteria per le
prestazioni (quando non addirittura impossibile da
implementare), il problema consiste più nel fatto
che non si conoscono abbastanza le regole inferenziali
del motore, il che si ripercuote inevitabilmente sulle
prestazioni. Spesso basta una subquery messa nel posto
"sbagliato" a far degenerare le prestazioni in maniera
"drammatica" - come dicono gli americani - o addirittura
il fatto che una colonna sia indicizzata prima o dopo di
un'altra o che venga usata o meno una funzione di
aggregazione...
--
Er Roscio.

 Ora un po' di cose si chiariscono. Lo dico senza polemica.
Fermo restando che la realtà nel 99% dei casi è quella
che hai descritto tu (il cliente - o il capo - vuole tutto e subito),
posso assicurarti che le cose non cambiano di molto anche
in un ambiente altamente professionale e integrato, dove
tutto "dovrebbe" funzionare a meraviglia, salvo poi constatare
che "per qualche motivo oscuro" non funziona un ca@@o !!!...
:-)))))
La verità è che in questo campo, la teoria è troppo lontana
dalle implementazioni reali, e proprio applicando alla lettera
la teoria al caso reale, sorgono così tanti problemi di
"compatibilità" del modello che gli accrocchi da aggiungere
per farlo funzionare vanificano di fatto tutti gli sforzi organizzativi
per renderlo "teoricamente efficiente".
Esempio classico, la normalizzazione: provate a normalizzare
alla 5^ f.n. un semplicissimo magazzino e vedete se non ci
si impegola in mille tabelline insulse variamente relazionate
e che è praticamente impossibile manutenere, quando con
quattro tabelle suggerite dal buon vecchio "ciodo de fero vecio"
dell'informatica si può risolvere il tutto in maniera chiara, elegante
ed efficiente.
--
Er Roscio.

 aggregazione...
penso che conoscere gli strumenti con i quali si lavora sia una necessaria
condizione operativa... non credo che il fatto di usarli a casaccio debba
far precipitare tali strumenti a meri Index Manager ed utilizzarli in
maniera Isam... SqlServer fornisce anche un Profiler, sgustoso quanto vuoi
da usare, ma sicuramente di aiuto in tanti piccoli/grandi momenti dello
sviluppo di un software... chiaramente, in generale, non sempre potranno
essere prese le decisioni giuste al 100% relativamente agli indici, per
questa query manca un indice, per quell'altra sarebbe meglio un indice di
copertura composto cosi' e cosi', ma generalemte ritengo che tale lavoro di
tuning debba essere fatto.... probabilmente dando piu' importanza operativa
(almeno nella mia visione...) alla query del povero ragioniere al quale
serve sapere immediatamente lo stato dei castelletti bancari rispetto al
report del megadirettoregalattico che vuole sapere quanti strappi di carta
igienica utilizzano i dipendenti... poi le priorita' al limite si
aggiustano, ma comunque vengono analizzate..
relativamene agli altri tuoi post...
posso darti ragione sui Case tools, ma resto comunque della mia idea per una
corretta implementazione con "piccoli" aggiustamenti, sono fortemente
contrario ad un'idea di un magazzino buttato li' perche "deve" funzionare...
anche quello fatto con grazia "deve" funzionare.... trasgredire di tanto in
tanto le regole lo accetto e penso debba rientrare nella normale ottica di
una mente aperta (non necessariamente la mia), ma farne di questa
trasgressione una bandiera appoggiata da slogan "tanto non potrebbe
funzionare come loro dicono che funzioni" lo ritengo profondamente errato.
ripeto, dipende da me studiare gli attrezzi con i quali lavoro, in qualsiasi
campo, e dipende ancora da me tentare di usarli al meglio, sia della mia
comprensione, che della loro effettiva portata. un minimo di
professionalita' penso sia richiesta anche a noi....
non sono un amante della tecnologia o dell'architettura fine a se stessa,
deve essere sempre calzata per il problema da risolvere...
sempre e comunque my $0,02
saluti e senza rancore


 rarissime eccezioni).
Spendendo un po' di soldini si comprano tanti libretti che
spiegano tutto quello che vuoi, poi con un buon metodo di
 lavoro e un po' di esperienza i risultati vengono

 saluti e senza rancore
Rancore ?... E che c'entra il rancore ?... :-)))
--
Er Roscio.

  lavoro e un po' di esperienza i risultati vengono
Fammi qualche titolo di libretti che spiegano come funziona
il tale database o il talaltro, specificando se processa prima
le statistiche delle chiavi ripetute piuttosto che gli indici
secondari piuttosto che le relazioni, ecc...
--
Er Roscio.

 secondari piuttosto che le relazioni, ecc...
Per oracle nella OTN trovi tutto quello che vuoi (
OTN.ORACLE.COM
)
Per SQL Server
INSIDE SQLSERVER 2000
SQLSERVER PERFORMANCE TOUNING
entrambi di MS Press (Mondadori)
senza cattiveria, o rancori
benny

 per modificare la strategia di ricerca.
Informazioni reperibili, non sempre facilment, ma reperibili!!!
benny