View Full Version : [SQL]Chiavi Primarie ed Esterne
RaouL_BennetH
25-06-2009, 16:52
Ciao a tutti :)
Considerando queste entità:
Persona
(id, nome, cognome)
Dipendente : Persona
(ruolo, personaId, indirizzoId)
Indirizzi
(id_indirizzo, domicilio, comune, provincia, cap)
Ho definito le due tabelle 'principali'
CREATE TABLE Persone(id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
Nome varchar(25),
Cognome varchar(25));
CREATE TABLE Indirizzi(id_indirizzo INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
domicilio varchar(100),
comune varchar(80),
provincia char(2),
cap varchar(5));
Vorrei capire:
1) Nella tabella dipendente, è necessaria una chiave primaria?
2) Nella tabella dipendente, le chiavi esterne sono relative alle chiavi primarie di Indirizzi e Persone, posso mettere due chiavi esterne sulla stessa tabella?
3) C'è modo per impedire anche per il più incredibile dei casi, che vengano inseriti nella tabella dipendente degli id relativi a persone o indirizzi che non esistono nelle due tabelle?
Grazie mille per i chiarimenti :)
RaouL.
Trigger2009
25-06-2009, 17:19
Ciao a tutti :)
Considerando queste entità:
Persona
(id, nome, cognome)
Dipendente : Persona
(ruolo, personaId, indirizzoId)
Indirizzi
(id_indirizzo, domicilio, comune, provincia, cap)
Ho definito le due tabelle 'principali'
CREATE TABLE Persone(id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
Nome varchar(25),
Cognome varchar(25));
CREATE TABLE Indirizzi(id_indirizzo INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
domicilio varchar(100),
comune varchar(80),
provincia char(2),
cap varchar(5));
Vorrei capire:
1) Nella tabella dipendente, è necessaria una chiave primaria?
2) Nella tabella dipendente, le chiavi esterne sono relative alle chiavi primarie di Indirizzi e Persone, posso mettere due chiavi esterne sulla stessa tabella?
3) C'è modo per impedire anche per il più incredibile dei casi, che vengano inseriti nella tabella dipendente degli id relativi a persone o indirizzi che non esistono nelle due tabelle?
Grazie mille per i chiarimenti :)
RaouL.
mmm credo proprio che in MySql sia impossibile creare una tabella senza chiave primaria...per poter accedere ai record...anche se non vorrei sbagliarmi...
Comunque fatto stà che a livello logico devi sempre mettere una chiave primaria univoca, nella tabella Dipendenti metterei personaId che identifica univocamente un dipendente.
Mentre in indirizzi metterei Id_Indirizzo che identifica univocamente un indirizzo.
Considera che se hai una tabella che logicamente non contiene dati per forza univoci si mette un campo auto_increment per avere una chiave primaria o si usano più campi della tabella che messi insieme sono univoci...
2 e 3) Si se crei le tabelle Dipendente imponendo il vincolo di integrità referenziale ai campi delle altre due tabelle...devi usare i references nella creazione della tabella Dipendenti che il campo IdDipendente fa riferimento al campo ID di persona ed il campo IdIndirizzo fa riferimento al campo IdIndirizzo di indirizzo
Così se ad esempio provi ad inserire un dipendente con un indirizzo che non esiste dentro la tabella indirizzi ti da un errore e non te lo fa inserire preservando i vincoli di integrità referenziale dei tuoi dati.
Questo se usi tabelle InnoDB, con MyISAM non dovresti poterlo fare e te lo dovresti fare a mano con i trigger ma sarebbe una caciara...quindi usa InnoDB.
Ciao
Andrea
RaouL_BennetH
25-06-2009, 17:32
mmm credo proprio che in MySql sia impossibile creare una tabella senza chiave primaria...per poter accedere ai record...anche se non vorrei sbagliarmi...
Comunque fatto stà che a livello logico devi sempre mettere una chiave primaria univoca, nella tabella Dipendenti metterei personaId che identifica univocamente un dipendente.
Mentre in indirizzi metterei Id_Indirizzo che identifica univocamente un indirizzo.
Considera che se hai una tabella che logicamente non contiene dati per forza univoci si mette un campo auto_increment per avere una chiave primaria o si usano più campi della tabella che messi insieme sono univoci...
2 e 3) Si se crei le tabelle Dipendente imponendo il vincolo di integrità referenziale ai campi delle altre due tabelle...devi usare i references nella creazione della tabella Dipendenti che il campo IdDipendente fa riferimento al campo ID di persona ed il campo IdIndirizzo fa riferimento al campo IdIndirizzo di indirizzo
Così se ad esempio provi ad inserire un dipendente con un indirizzo che non esiste dentro la tabella indirizzi ti da un errore e non te lo fa inserire preservando i vincoli di integrità referenziale dei tuoi dati.
Questo se usi tabelle InnoDB, con MyISAM non dovresti poterlo fare e te lo dovresti fare a mano con i trigger ma sarebbe una caciara...quindi usa InnoDB.
Ciao
Andrea
Ciao e grazie per la risposta :)
Vorrei solo precisare che non utilizzo MySql come base dati.
I 'motori' che ho a disposizione sono PostgreSql e, forse (ci spero vivamente), Sql Server (non nella versione express).
Ho messo [SQL] nel titolo perchè mi interessa capire come funziona il tutto in qualsiasi engine che sia standard.
Grazie :)
RaouL.
Trigger2009
25-06-2009, 17:39
Ciao e grazie per la risposta :)
Vorrei solo precisare che non utilizzo MySql come base dati.
I 'motori' che ho a disposizione sono PostgreSql e, forse (ci spero vivamente), Sql Server (non nella versione express).
Ho messo [SQL] nel titolo perchè mi interessa capire come funziona il tutto in qualsiasi engine che sia standard.
Grazie :)
RaouL.
Aspetta stai facendo confusione !!!
PostgreSQL e SQL Server NON SONO MOTORI, sono DBMS (ovvero i software che servono a creare e gestire le basi di dati) così come MySql.
Io ti parlo di tipi di tabelle: con questi DBMS tu puoi gestire tabelle realizzate con motori diversi che sono appunto InnoDB, MyIsam, Falcon e tantissimi altri...
In pratica ogni motore ti rappresenta in memoria le tabelle in modo diverso ed ognuno di essi ha dei pro e dei contro (apparte alcuni vecchissimi che non si usano più)...in fin dei conti quelli usati frequentemente sono InnoDB e MyIsam...vedila così: puoi avere due tipi di tabelle diverse:
Le tabelle InnoDB ti garantiscono la possibilità di avare vincoli di integrità referenziale come ti ho appena spiegato
Le tabelle MyIsam sono più veloci a fare certe operazioni e puoi creare indici fulltext per ricerche testuali molto potenti ma hanno il grosso handicap di non garantire l'integrità referenziale e se la vuoi devi fartela a mano scrivendo dei trigger (un bel casino).
Per scopi generici viene usato InnoDB che è abbastanza performante e ti garantisce l'integrità referenziale.
Però questi tipi di tabelle sono valide per praticamente tutti i DBMS e non sono i DBMS stessi come tu hai capito.
Spero di averti tolto un po' di confusione che avevi in testa :)
1) non necessariamente, ma di solito io lo faccio
2) si certo puoi avere anche infinite chiavi esterne in una tabella
3) lo fa automaticamente il database quando crei la chiave esterna (parlo per postgresql, ma dovrebbe essere una cosa comune quando si parla di chiavi esterne)
RaouL_BennetH
25-06-2009, 17:52
Aspetta stai facendo confusione !!!
PostgreSQL e SQL Server NON SONO MOTORI, sono DBMS (ovvero i software che servono a creare e gestire le basi di dati) così come MySql.
Io ti parlo di tipi di tabelle: con questi DBMS tu puoi gestire tabelle realizzate con motori diversi che sono appunto InnoDB, MyIsam, Falcon e tantissimi altri...
In pratica ogni motore ti rappresenta in memoria le tabelle in modo diverso ed ognuno di essi ha dei pro e dei contro (apparte alcuni vecchissimi che non si usano più)...in fin dei conti quelli usati frequentemente sono InnoDB e MyIsam...vedila così: puoi avere due tipi di tabelle diverse:
Le tabelle InnoDB ti garantiscono la possibilità di avare vincoli di integrità referenziale come ti ho appena spiegato
Le tabelle MyIsam sono più veloci a fare certe operazioni e puoi creare indici fulltext per ricerche testuali molto potenti ma hanno il grosso handicap di non garantire l'integrità referenziale e se la vuoi devi fartela a mano scrivendo dei trigger (un bel casino).
Per scopi generici viene usato InnoDB che è abbastanza performante e ti garantisce l'integrità referenziale.
Però questi tipi di tabelle sono valide per praticamente tutti i DBMS e non sono i DBMS stessi come tu hai capito.
Spero di averti tolto un po' di confusione che avevi in testa :)
Uh.. forse me ne hai fatta venire di più :D
Cioè, in postgresql ci sono tabelle innodb e myisam :confused:
@vizzz
Chiarissimo grazie :)
Ciao, vorrei farti osservare che potresti anche "inglobare" il dipendente nella tabella "persona". Questo tipo di soluzione, parlando di ristrutturazione di gerarchie, si chiama "mantenimento dell'entità genitore" e ha senso se la maggior parte delle persone è anche dipendente.
La tabella persona sarebbe quindi
CREATE TABLE Persone(id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
Nome varchar(25),
Cognome varchar(25),
Ruolo TIPO DEFAULT NULL,
indirizzo_id TIPO DEFAULT NULL)
Le persone dai dipendenti li riconosceresti dal fatto che hanno ruolo = null.
Tra l'altro non capisco perchè l'indirizzo ha un suo id, in realtà dovrebbe avere la chiave esterna della persona.O Sbaglio?
Trigger2009
25-06-2009, 19:41
Uh.. forse me ne hai fatta venire di più :D
Cioè, in postgresql ci sono tabelle innodb e myisam :confused:
@vizzz
Chiarissimo grazie :)
In MySql ci sono tantissimi tipi di tabelle e le più usate sono InnoDB e MyIsam, credo che anche postgresql sia simile e probabilmente InnoDB e MyIsam saranno implementate...
Però forse dovresti leggerti qualcosa perchè mi pare che le tue basi siano un pochino debolucce...senza offesa...
Trigger2009
25-06-2009, 19:42
Ciao, vorrei farti osservare che potresti anche "inglobare" il dipendente nella tabella "persona". Questo tipo di soluzione, parlando di ristrutturazione di gerarchie, si chiama "mantenimento dell'entità genitore" e ha senso se la maggior parte delle persone è anche dipendente.
La tabella persona sarebbe quindi
CREATE TABLE Persone(id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
Nome varchar(25),
Cognome varchar(25),
Ruolo TIPO DEFAULT NULL,
indirizzo_id TIPO DEFAULT NULL)
Le persone dai dipendenti li riconosceresti dal fatto che hanno ruolo = null.
Tra l'altro non capisco perchè l'indirizzo ha un suo id, in realtà dovrebbe avere la chiave esterna della persona.O Sbaglio?
Per curiosità si tratta di una denormalizzazione giusto?
Per curiosità si tratta di una denormalizzazione giusto?
Non lo so, io l'ho sempre chiamato "eliminazione di gerarchie di generalizzazione".
Trigger2009
25-06-2009, 19:58
Non lo so, io l'ho sempre chiamato "eliminazione di gerarchie di generalizzazione".
Capito, cmq credo che sia una denormalizazzione in quanto si stà racchiudendo un'informazione spezzabile in più tabelle in una sola tabella aumentandone i campi :)
[MEGA OT]
Ah cmq con quel triggerino ho risolto in maniera alternativa :D Praticamente c'erano 2 trigger diversi sulla stessa tabella ma non gli piace che ce ne siano 2 (anche se fanno operazioni diverse tra loro)...allora ho riunito tutto in uno e funziona
Ora però mi sono inchiodato su un altro trigger, poi posto ahaha...GIURO CHE è L'ULTIMO :D [/MEGA OT]
Capito, cmq credo che sia una denormalizazzione in quanto si stà racchiudendo un'informazione spezzabile in più tabelle in una sola tabella aumentandone i campi :)
Con denormalizzazione probabilmente tu intendi il passaggio da uno schema in una certa forma normale a una meno raffinata che non è proprio quello che ho suggerito io a RaouL_BennetH.
Trigger2009
25-06-2009, 20:22
Con denormalizzazione probabilmente tu intendi il passaggio da uno schema in una certa forma normale a una meno raffinata che non è proprio quello che ho suggerito io a RaouL_BennetH.
mmm non per forza meno raffinata...da quello che ci hanno fatto vedere a lezione..a volte hai il tuo bel DB super normalizzato...hai lo schema fisico e per fare delle ottimizzazioni lo vai a denormalizzare perchè poi certe query sono più veloci in quanto anche se hai una certa ridondanza di dati magari denormalizzando vai ad aggiungere un campo in più ad una tabella e quando fai una query magari fai un join in meno :)
RaouL_BennetH
26-06-2009, 08:17
In MySql ci sono tantissimi tipi di tabelle e le più usate sono InnoDB e MyIsam, credo che anche postgresql sia simile e probabilmente InnoDB e MyIsam saranno implementate...
Però forse dovresti leggerti qualcosa perchè mi pare che le tue basi siano un pochino debolucce...senza offesa...
Nessuna offesa tranquillo :)
Comunque, documentandomi dal sito ufficiale di postgresql e anche su wikipedia, posso dire di essere sicuro di aver capito che postgresql NON usa ne InnoDb ne MyIsam.
Inoltre, a conferma anche di molti esperti e professionisti, MySql NON è sql standard.
Nessuna offesa tranquillo :)
Inoltre, a conferma anche di molti esperti e professionisti, MySql NON è sql standard.
Si è vero, da ne so non implementa l'operatore EXCEPT, i vincoli di CHECK, la CREATE DOMAIN e non so che altro.
Postgres invece di quanto ne so implementa molte più funzionalitù dello standard, se non tutte, oltre ad offrire, come un po' tutti i dbms, particolari funzionalità e particolari dialetti per quanto riguarda le funzioni pl/sql
RaouL_BennetH
26-06-2009, 08:50
Ciao, vorrei farti osservare che potresti anche "inglobare" il dipendente nella tabella "persona". Questo tipo di soluzione, parlando di ristrutturazione di gerarchie, si chiama "mantenimento dell'entità genitore" e ha senso se la maggior parte delle persone è anche dipendente.
La tabella persona sarebbe quindi
CREATE TABLE Persone(id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
Nome varchar(25),
Cognome varchar(25),
Ruolo TIPO DEFAULT NULL,
indirizzo_id TIPO DEFAULT NULL)
Le persone dai dipendenti li riconosceresti dal fatto che hanno ruolo = null.
Tra l'altro non capisco perchè l'indirizzo ha un suo id, in realtà dovrebbe avere la chiave esterna della persona.O Sbaglio?
Ciao :)
Per quanto riguarda questa applicazione, la maggior parte delle persone non è di tipo dipendente, anzi, diciamo pure che non c'è un tipo che ha 'maggioranza' :)
Per quanto riguarda l'indirizzo invece, ho pensato questo:
Dato che una marea di entità hanno un indirizzo (dipendenti, fornitori, sedi aggiuntive dei fornitori, clienti, sedi aggiuntive, consulenti, avvocati e blabla), ho pensato di creare un'unica entità indirizzo. Qualsiasi altra cosa che ha un'indirizzo, ne prende semplicemente l'id.
Le persone dai dipendenti li riconosceresti dal fatto che hanno ruolo = null.
Non mi sembra poi tanto bello...poi per carità, può avere senso per le prestazioni.
Sinceramente non mi tornano molto queste tabelle...
Persona
(id, nome, cognome)
E qui ci siamo...
Dipendente : Persona
(ruolo, personaId, indirizzoId)
Cosa vuoi rappresentare qui ? Una persona può avere diversi indirizzi ? Ma sono indirizzi di residenza delle persone (quindi ne esiste uno solo) o semplicemente indirizzi presso i quali una persona svolge un certo ruolo ?
Nel secondo caso va bene e la tabella è tutta chiave (cioè tutti gli attributi fanno parte della chiave primaria) se una persona può ricoprire più ruoli allo stesso indirizzo, altrimenti la chiave è (personaId, indirizzoId).
Nel primo caso devi fondere Persona e indirizzo, lasciando come chiave id.
Per quanto riguarda l'indirizzo invece, ho pensato questo:
Dato che una marea di entità hanno un indirizzo (dipendenti, fornitori, sedi aggiuntive dei fornitori, clienti, sedi aggiuntive, consulenti, avvocati e blabla), ho pensato di creare un'unica entità indirizzo. Qualsiasi altra cosa che ha un'indirizzo, ne prende semplicemente l'id.
Nel tuo caso si possono avere indirizzi senza che ci siano entita' che li usino: non mi sembra molto logico.
Normalmente una entita' di quelle che tu hai citato ha almeno uno o piu' indirizzi (ad esempio un'azienda puo' avere un recapito fiscale, uno per la merce, ecc.) e quindi una soluzione piu' corretta dovrebbe prevedere la possibilita' di avere piu' indirizzi assegnati alla stessa entita' ad esempio:
CREATE TABLE Indirizzi(
persone_id,
tipo_indirizzo varchar(30),
domicilio varchar(100),
comune varchar(80),
provincia char(2),
cap varchar(5));
Il problema è che non sappiamo bene quale significato abbiano queste entità. Se non lo sappiamo non possiamo nemmeno determinare la forma migliore per rappresentarle.
Ad esempio, indirizzo potrebbe rappresentare l'indirizzo di una sede, oppure l'indirizzo di casa, o potrebbe rappresentare una rubrica indirizzi generica ed utilizzabile da relazioni diverse, in tal caso avrebbe senso per come è stata scritta.
Dato che una marea di entità hanno un indirizzo (dipendenti, fornitori, sedi aggiuntive dei fornitori, clienti, sedi aggiuntive, consulenti, avvocati e blabla), ho pensato di creare un'unica entità indirizzo. Qualsiasi altra cosa che ha un'indirizzo, ne prende semplicemente l'id.
Ok, questo ha perfettamente senso.
Però tutto deve essere modificato.
sede (id, denominazione, descrizione, idindirizzo)
persona (id, nome, cognome, etc, idindirizzo)
ruolo (ruolo, iddipendente, idsede) con chiave (iddipendente, idsede)
dipendente (id, idpersona, tipo_contratto, scadenza, etc, etc)
indirizzo (id, indirizzo, comune, provincia, cap)
Volendo essere pignoli, per minimizzare la ridondanza:
indirizzo (id, indirizzo, altro, idlocalita)
localita(id, localita, provincia, CAP)
Tra l'altro questo la tabella con i CAP si trova già pronta.
Addirittura si potrebbe estrarre l'informazione sul ruolo, visto che bene o male c'è duplicazione.
ruolo (id, denominazione, descrizione)
assegnazione (idruolo, iddipendente, idsede) con chiave (iddipendente, idsede) se una persona può avere un solo ruolo in una determinata sede, con chiave (idruolo, iddipendente, idsede) se una persona può avere diversi ruoli in una determinata sede.
Se questi dati servissero in altre relazioni, basterebbe estrarre un idassegnazione ed usarlo come chiave primaria.
RaouL_BennetH
26-06-2009, 10:35
EDIT, non avevo ancora letto i nuovi messaggi di Cionci :)
Ok, questo ha perfettamente senso.
Però tutto deve essere modificato.
sede (id, denominazione, descrizione, idindirizzo)
persona (id, nome, cognome, etc, idindirizzo)
ruolo (ruolo, iddipendente, idsede) con chiave (iddipendente, idsede)
dipendente (id, idpersona, tipo_contratto, scadenza, etc, etc)
indirizzo (id, indirizzo, comune, provincia, cap)
Volendo essere pignoli, per minimizzare la ridondanza:
indirizzo (id, indirizzo, altro, idlocalita)
localita(id, localita, provincia, CAP)
Tra l'altro questo la tabella con i CAP si trova già pronta.
Addirittura si potrebbe estrarre l'informazione sul ruolo, visto che bene o male c'è duplicazione.
ruolo (id, denominazione, descrizione)
assegnazione (idruolo, iddipendente, idsede) con chiave (iddipendente, idsede) se una persona può avere un solo ruolo in una determinata sede, con chiave (idruolo, iddipendente, idsede) se una persona può avere diversi ruoli in una determinata sede.
Se questi dati servissero in altre relazioni, basterebbe estrarre un idassegnazione ed usarlo come chiave primaria.
Concordo su quasi tutto, anche se hai ridotto il tutto alla gestione dei dipendenti :D, ma rimane comunque il fatto che se non si ha la necessita' di assegnare lo stesso indirizzo a piu' entita', e qui viene eliminata dal fatto che esiste l'entita' sede che ha un suo indirizzo unico altrimenti sarebbe un'altra sede, la tabella indirizzi è inutile a meno che non si abbia la necessita' di assegnare piu' indirizzi alla stessa entita' e in quel caso si dovrebbe avere la tabella indirizzi che punta all'entita' in questione (ad esempio un cliente) e non viceversa o, al limite, si dovrebbe interporre una tabella di assegnazione, come hai fatto per il caso dei ruoli multipli, cosa che potrebbe coprire tutte le possibili eventualita'.
L'avevo lasciato appunto aperto alla gestione di nuove relazioni che necessitano di indirizzo e persone...
Ad esempio:
clienti (id, denominazione, p.iva, idsede_legale, idsede_amminsitrativa, idpersona_referente)
etc etc
Ad esempio: un referente potrebbe avere come indirizzo (per spedire la posta) l'indirizzo della sede legale o della sede amminsitrativa o addirittura un altro completamente diverso.
Non mi sembra poi tanto bello...poi per carità, può avere senso per le prestazioni.
Effettivamente inq uesto genere di ristrutturazione si introduce un campo che funge da discriminante per determinare il tipo di entità che rappresenta quel record.
Come ripeto, la soluzione che ho proposto è utile se si stima che la maggior parte delle persone sono anche dipendenti, altrimenti no perchè si andrebbero a generare un sacco di valori nulli.
Comunque è difficile proporre una soluzione efficiente ed ottimizzata senza avere uno schema con le associazioni e le relative cardinalità.
RaouL_BennetH
26-06-2009, 10:52
Concordo su quasi tutto, anche se hai ridotto il tutto alla gestione dei dipendenti :D, ma rimane comunque il fatto che se non si ha la necessita' di assegnare lo stesso indirizzo a piu' entita', e qui viene eliminata dal fatto che esiste l'entita' sede che ha un suo indirizzo unico altrimenti sarebbe un'altra sede, la tabella indirizzi è inutile a meno che non si abbia la necessita' di assegnare piu' indirizzi alla stessa entita' e in quel caso si dovrebbe avere la tabella indirizzi che punta all'entita' in questione (ad esempio un cliente) e non viceversa o, al limite, si dovrebbe interporre una tabella di assegnazione, come hai fatto per il caso dei ruoli multipli, cosa che potrebbe coprire tutte le possibili eventualita'.
Questa necessità c'è :)
Basta pensare alla sede di un cliente dove il dipendente va a lavorare.
Ciao a tutti :)
Considerando queste entità:
Persona
(id, nome, cognome)
Dipendente : Persona
(ruolo, personaId, indirizzoId)
Indirizzi
(id_indirizzo, domicilio, comune, provincia, cap)
Vorrei capire:
1) Nella tabella dipendente, è necessaria una chiave primaria?
2) Nella tabella dipendente, le chiavi esterne sono relative alle chiavi primarie di Indirizzi e Persone, posso mettere due chiavi esterne sulla stessa tabella?
3) C'è modo per impedire anche per il più incredibile dei casi, che vengano inseriti nella tabella dipendente degli id relativi a persone o indirizzi che non esistono nelle due tabelle?
Grazie mille per i chiarimenti :)
RaouL.
la tabella dipendente e' la classica tabella associativa.
Per la quale puoi mettere la chiave primaria multipla (personaId, indirizzoId), e ciascun campo in chiave straniera verso la tabella entita' relativa.
Non si capisce "ruolo" che senso abbia in questa tabella.
Forse che ogni persona, a seconda dell'indirizzo, puo' avere un ruolo diverso? Se si', allora va bene li', altrimenti migrala sulla tabella Persona, se puo' avere un ruolo solo, oppure crea la tabella apposta di associativa ruoli come porposto da Cionci (anch'essa con la chiave primaria su 2 campi)
Questa necessità c'è :)
Basta pensare alla sede di un cliente dove il dipendente va a lavorare.
In realta' non è vero in quanto l'entita' dipendente lo devi associare all'entita' cliente (per sapere a chi intestare la fattura), e da questa associazione ricavi l'indirizzo dove va a lavorare: ovvero l'indirizzo del cliente.
Se prevedi per l'entita' cliente piu sedi di lavoro questa entita' sede cliente deve essere definita ed ovviamente associata all'entita' cliente, per cui al massimo avresti l'associazione dell'entita' dipendente all'entita' sede cliente da cui ricavi l'indirizzo.
E ritorniamo sempre al punto che ad una entita' indirizzo deve corrispondere sempre un'altra entita' che ne sia titolare.
Negli esempi finora riportati invece si ha la possibilita' di avere indirizzi senza che siano assegnati ad una entita' e che per creare un entita' di tipo persona, cliente, sede, ecc.. debba prima essere creata un'entita' indirizzo. Vogliamo parlare di cosa comporterebbe, all'atto pratico, l'implementazione di una soluzione del genere ?
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.