Newsgroup: it.comp.lang.visual-basic
Titolo: EF code first, colonne multiple Primary Key

Ciao a tutti,
sto muovendo i primi passi con EF (
VB.NET
), partendo da una logica di
modellazione delle entità prima del DB.
 
Avrei delle tabelle con chiavi primarie multiple, visto che se posso evito
di usare i campi identity, vorrei sapere come fare.
 
Cercando su internet, non mi è parso molto chiaro immediato.
Premetto che utilizzo VS2010 SP1 liscio, senza altre aggiunte.
 
Grazie


Ciao Andrea,
in che senso "vorrei sapere come fare."?
 
Ti serve sapere come creare il context che contenga una relazione molti 
a molti tra due oggetti? Che nel db sia poi proiettato come
T1(1) (n)Tponte(n) (1)T2
 
ciao
stefano
 
 
 


Per semplicità vorrei sapere come creare una relazione del tipo:
- Cliente
- Articolo
- ClientePrezzo: ID_Pk, IdCliente, IdArticolo, Prezzo
 
Non avendo senso il campo ID_Pk, ma la chiave per me è
idcliente+idarticolo, vorrei poterla creare dal modello EF.
 
Tra l'altro ho installato nuget e aggiunto il pacchetto EF 5.0, solo che
non ho ben capito se il mio modello creato precedentemento è già aggiornato
o devo far qualcosa.


 
Ciao Andrea,
sono anche io agli inizi con EF e pur avendo fatto un breve e rapido 
corso poco tempo fa, ho necessità di mettere in pratica quanto visto 
altrimenti i concetti scivolano via in fretta.
 
Ora non ho sotto mano gli appunti e a memoria non ricordo, però posso 
segnalarti questo
http://www.domusdotnet.org/media/23731/entity%20framework%20code%20first.pdf
 
 
che spero possa esserti d'aiuto.
ciao
stefano

 di usare i campi identity, vorrei sapere come fare.
 
Metti l'attributo Key sulle proprietà della tua entità che rappresentano 
la chiave:
 
http://tinyurl.com/lahba4f
 
 
-- 
r--r--r--
 

 stefano
 
Grazie, scaricata e gli dò un occhio il prima possibile.

 
http://tinyurl.com/lahba4f
 
 
Mi sa che la totale inesperienza in questo campo mi ha fatto sbagliare, in
realtà credo di aver usato un approccio Model first, in quanto le entità
sono state graficamente creando il modello.
 
Quindi rigiro la domanda in che modo farlo in Model First? Tale approccio
va comunque "bene" o è meglio orientarsi ad altro?

 va comunque "bene" o è meglio orientarsi ad altro?
 
Faccio una domanda, perché vuoi utilizzare EF?
Perché pensi che ti serva davvero o per imparare?
 
EF, ho visto, ti semplifica la vita, ma è un toro che va saputo 
padroneggiare altrimenti qualche cornata bisogna metterla in conto.
 
In model first, innanzi tutto, il DB deve essere fatto con i dovuti 
crismi, relazioni in primis. Per andare bene, credo che vada benissimo, 
dipende da qual è il tuo obiettivo.
 
ciao
stefano
 


Devo fare un progettino interno per gestione lavori/clienti.
Ho cominciato quindi a disegnare il modello per vedere un po' quali entità
servono e che relazioni (e sottoporlo anche a discussione interna).
Da lì con un tasto mi creo il DB in automatico.
 
Invece di disegnare lo schema su open office o simile e poi ricreare DB e
classi a mano su .NET.
 
L'ho preso poi come test per vedere l'applicabilità ai sw che dovremo
sviluppare.
 
Quindi per capirci, ci sono questi tre approcci
- DB First: creo il DB e poi mi faccio creare lo schema
- Model First: creo lo schema grafico, e mi crea classi/DB
- Code First: creo le classi che poi aggancio dove/come?
             (me lo leggerò in quella dispensa)
 
Volevo capire se qualcuno di questi era già "obsoleto" prima di partire.

 di usare i campi identity, vorrei sapere come fare.
 
Googlando qua e là mi sono imbattuto in questa roba qui:
http://stackoverflow.com/questions/5466374/composite-key-with-ef-4-1-code-first
 
http://stackoverflow.com/questions/14873169/creating-composite-key-entity-framework
 
http://stackoverflow.com/questions/2733254/how-do-i-map-a-composite-primary-key-in-entity-framework-4-code-first/2912896#2912896
 
 
HTH,
Giulio
 
-- 
 
 

 di usare i campi identity, vorrei sapere come fare.
 
Al di la del fatto che non ho la piï¿œ pallida idea di come farlo perchï¿œ 
non uso EF, una domanda: perchï¿œ non usi campi identity?
 
le chiavi surrogate sarebbero sempre da preferire alle chiavi naturali.
 
.m
 
-- 
blog @ //
milestone.topics.it
 
 
 

 le chiavi surrogate sarebbero sempre da preferire alle chiavi naturali.
 
Riguardo a questo avevo aperto anche un post.
Sembra anche che su internet ci siano tante scuole di pensiero
contrastanti.
 
Nella mia esperienza, mi sono reso conto, che i campi identity
auto-increment sono scomodi e noiosi quando si trasferiscono dati da DB
diversi (key da riassociare su tabelle relazionate).
Di contro � scomodo avere una chiave composta a livello di join o tabelle
figlio su diversi livelli.
Forse avere un campo chiave unico, ma non necessariamente autogenerato,
potrebbe essere la cosa pi� comoda.
 
Non mi dispiacerebbe leggere qualcosa su questo argomento, che ne evidenzia
difetti o pregi dei vari sistemi.
 
Come mai dici che le chiavi surrogate sono da preferire?

 Come mai dici che le chiavi surrogate sono da preferire?
 
perchï¿œ i requisiti cambiano nel tempo e le chiavi naturali no, oltre al 
dettaglio fadtidioso che scarichi sull'utente la generazione/garanzia 
della chiave con tutto quello che questo potrebbe comportare. Infine 
devi avere la certezza che una chiave naturale sia veramente "unique", 
pensa al codice fiscale (la mia banca lo usa come PK di alcune 
tabelle...) che mega fail :-)


 tabelle...) che mega fail :-)
 
Di contro però ci sono degli scenari in cui la cosa si complica. Poniamo
che un agente della banca va fuori con il tablet senza internet, a cercare
nuovi clienti o proporre nuovi piani ai clienti esistenti.
 
Lui inserirà, modificherà dei dati, dei clienti, degli "ordini" o simile, e
probabilmente non avrà l'anagrafica locale. Alla fine la procedura di
sincronizzazione, probabilmente dovrà guardare comunque il cod.fisc per
vedere se quella persona c'è già no?

 vedere se quella persona c'è già no?
 
certo, ma un conto è cercare per qualcosa che supponi/presumi essere 
"unique" un altro è essere certo che quella cosa sia unique e che lo 
sarà sempre, oltre al dettaglio che il requisito potrebbe cambiare e 
costringerti ad allargare la base di inforazioni che usi per gestire ad 
esempio una chiave composta.
 
In quello scenario un bel guid per la PK (così lo puoi generare 
off-line) e poi magari, se è un requisito, un indice unique sul codice 
fiscale.


 diversi (key da riassociare su tabelle relazionate).
 
Ciao Andrea,
tenderei a dire ... dipende.
 
Se il db in destinazione è già popolato allora gioco forza è molto 
probabile che gli id nel nuovo db saranno differenti da quelli presenti 
nel vecchio, quindi andrebbero opportunamente gestiti sia che si parta 
da un auto-increment sia che non lo si faccia.
 
Se il db di destinazione è vergine e se non vuoi crearti un gestore del 
"problema", se usi database SQL Server allora puoi sfruttare il comodo
SET IDENTITY_INSERT
per disabilitare temporaneamente l'auto incremento di id sulla tabella, 
auto incremento che riabiliterai una volta terminato l'inserimento.
 
In questo modo manterrai i vecchi id nel passaggio da un db ad un altro.
 
ciao
stefano

 fiscale.
 
Capito quello che intendi, anche se stravolte un po' il modo di pensare le
cose che avevo.

 da un auto-increment sia che non lo si faccia.
 
Dipende dagli scenari però, in alcuni casi si potrebbe andare a dritto.
Tipo i codici articolo, se il codice testuale è chiave, posso andare a
diritto, se ho una chiave ID, e voglio travasare un ordine, devo guardare
quell'articolo che ID ha sul DB di destinazione, e sostituirlo nel
trasferimento.
 
Esiste qualche regola sul trasferimento/sincronizzazione dati che si può
consultare per evitare di fare errori su cui tanti son già passati?