Newsgroup: it.comp.dotnet
Titolo: dataset e relazioni

Ciao
da pochi giorni studio ADO.net e stò utilizzando C# come linguaggio.
Ho creato un DB con Access e un paio di tabelle relazionate
Ho notato che se creo un dataset e non gli passo esplicitamente le info 
relative alle relazioni fra 2 tabelle, quest'ultimo non le 'acchiappa' 
direttamente dal databse ACCESS dove le relazioni sono definite.
Quindi (ipoteticamente) potrei anche indicare una relazione differente 
rispetto alle 2 tabelle caricate nel dataset dal DB ACCESS, e che non 
corrisponda a quella originale?
Quindi se ho compreso...
1 -Quindi potrei fare a meno di definire le relazioni in access e 
gestire tutto da ADO....
2 -il fatto che access memorizzi le relazioni e le informazioni di 
integrità referenziale è solo ad uso di access?
grazie

 referenziale è solo ad uso di access?
decisamente no, l'integrità referenziale ha lo scopo di proteggere i 
tuoi dati.
Stai comunque confondendo capre e cavoli e usando il DataSet come un 
in-memory database che è un approccio sbagliato.
.m
-- 
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com/profile/mauro
blog @ 
http://milestone.topics.it
whynot [ at ] topics [ dot ] it


nel ringraziarti per avermi risposto, potersti chiarire il tuo ultimo punto?
ancora grazie


Il DataSet nonostante assomigli molto ad un db nella sua struttura non 
deve essere usato per caricarci i dati in maniera strutturalmente 
uguale, quindi un rapporto 1:1 tra tabelle e relazioni. Il DataSet è da 
vedere più nell'ottima di primitivo Object Model dove le tabelle 
rappresentano un insieme di entità è quindi molto lecito e sensato 
avere più dataset, nella tua applicazione, la cui shape sia pensata per 
il caso d'uso. Un esempio utilizzando la solita rappresentazione trita 
e ritrita è quello del Person/Addresses. Un caso d'uso è:
A) come utente voglio poter stampare un elenco di persone e per ogni 
persona tutti i suoi indirizzi;
B) come utente voglio poter manipolare una persona e i suoi indirizzi;
nel primo caso probabilmente avresti una sola DataTable che continene 
il risultato della join fatta sul db e poi riraggrupperesti i dati 
direttamente all'interno del report, mentre nel secondo caso ha molto 
senso avere un DataSet con 2 DataTable relazionate tra loro.


 in-memory database che ï¿œ un approccio sbagliato.
Non necessariamente, anzi i dataset nascono proprio come un'implementazione del disconnected model con tanto di supporto built-in per la serializzazione.  Il fatto che il tuo approccio architetturale vede al centro il concetto di object model non significa che quello e' l'unico approccio possibile o legittimo (infatti personalmente suggerirei esattamente il contrario).
-LV

 gestire tutto da ADO....
Come gia' notato da Mauro, no: integrita' referenziale e i vari constraint ti consentono di proteggere i dati al livello di database, indipendentemente da chi o cosa tenta di manipolarli.  Se proprio devi fare un scelta, e' nel database che devono essere i vincoli, quelli al livello applicativo e ancora di piu' quelli al livello di interfaccia utente servono solo a rendere l'esperienza dell'utente piu' fluida e a minimizzare i round-trip (questo coincide con il discorso della validazione dell'input utente).
-LV

 ritrita è quello del Person/Addresses. Un caso d'uso
grazie

 -LV


 L'inghippo è quando il db diventa qualche centinaio di mega... :-)
e perchè le dimesioni divengono un inghippo?
grazie

 e perchè le dimesioni divengono un inghippo?
Lascio a Mauro le sue considerazioni che fin'ora condivido pienamente.
Posso dire che ho fatto specifici test sulle performance del dataset 
versus custom collection quando ho realizzato la mia 
http://rafcollection.codeplex.com
 (la cui prima versione è nata per una 
sessione che ho tenuto nel febbraio 2005) e la differenza è bella 
tosta. Ovviamente le perf del dataset peggiorano sempre più al crescere 
delle dimensioni.
In più tieni conto che il dataset non è strong-typed e quando crei 
quello strong-typed è "finto" perché sei sempre libero di usare gli 
oggetti base che identificano le colonne con le stringhe. Questo 
significa che aumenti notevolmente il rischio di errori di runtime.
BTW, sul progetto di codeplex le motivazioni che ho scritto nel 
documento che accompagna il progetto sono un espansione del concetto 
appena espresso da Mauro.
-- 
Raffaele Rialdi  
http://www.iamraf.net
Weblog: 
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile 
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - 
http://www.ugidotnet.org/

 e perchè le dimesioni divengono un inghippo?
oltre alle giuste considerazioni di Raff il rischio macroscopico è che 
se usi lo strumento senza conoscerne i limiti il rischio è quello di 
caricare, con una bella "Fill", i dati all'avvio dell'applicazione per 
poi scoprire che quando il db è 1,5gb (ma anche solo poche decine di 
mb) succede che le macchine client schiattano dopo aver ucciso il db 
server...ovviamente.


 macchine client schiattano dopo aver ucciso il db server...ovviamente.
+1
E sai la cosa triste? Che mediamente i clienti spendono volentieri i 
soldi per un super mega server invece di investire in architetture che 
possono facilmente evitare overload sui server.
Quando però arrivi al limite dei super mega server ti ritrovi con un 
blob di codice da cacciare dalla finestra.


 codice da cacciare dalla finestra.
tutto a vantaggio nostro :-)


 tutto a vantaggio nostro :-)
Tutto a vantaggio di chi fa le cose per bene.  Mi sembra che continuate a dare un po' troppe cose per scontate...
-LV

 Mi sembra che continuate a dare un po' troppe cose per scontate...
Non ho capito.



perdonatemi ancora
ma un buon libro / sito ove apprendere queste 'buone abitudini' di 
progettazione?
grazie