Schema ER di merda

Quote:

---

Originally Posted by Tanek

Non ho capito.
Se non crei la tabella di relazione come diamine le metti in relazione?
Eventualmente può esistere solo quella se i singoli elementi non hanno altri attributi.

---

Ti proporrò come mod anche di questa sezione al posto di Hador.
Faccio un esempio

FARMACO = PERSONA
TIPO_FARMACO = SESSO
REGIME_FARMACO = PESO

in una normale situazione io modellerei solo una identita(persona) e sesso e peso sarebbero semplici attributi
Ora necessito che sesso e peso diventino invece 2 identità oltre a persona.
Può esserci una relazione a 3 tra di loro?
Persona avrebbe una cardinalità 1,1 con entrambe, quindi avremme come chiave la concatenazione della sua piu le altre 2 dalle altre identità?

a me i db fanno merda :sneer:

Quote:

---

Originally Posted by Hador

a me i db fanno merda :sneer:

---

Sei proprio come ti descrivono

:(

cmq mi pare giusta l'ultima cosa che hai detto, anche se comunque è una porcata, però per i db devi chiedere agli altri.

Perchè è una porcata?
E se sesso e peso non fossero fissi e quindi avessi bisogno di gestirne anche eventuali cambiamenti senza impattare la tabella persona che ha qualche milione di record?(che poi è il mio caso per questo devo separare)

Ammesso abbia capito correttamente quello che vuoi, trovo molto inefficiente mettere sotto un'unica relazione 3 entita`di cui 2 (regime e tipologia) sono relazionate (0,n).

In generale, personalmente preferirei avere 2 relazioni distinte farmaco-regime e farmaco-tipologia ed eventualmente lasciare poi ad un join la possibilita` di fare l'unione delle due (magari prefiltrando, e quindi eliminando una buona fetta di calcoli). Questo per avere, nel caso pessimo, solo
E.n + E.m = E.(n+m)tuple
invece di
E.n.m tuple,

posto
E = numero istanze di farmaci
n = numero istanze di regimi
m = numero istanze di tipologie.

Poi ovviamente dipende dal contesto (in particolar modo dalla cardinalita` di farmaci, regimi e tipologie) e da quello che il cliente chiede.

ah spe tu vuoi usare come chiave primaria la tripla però... l'importante è che tu non usi solo la persona, altrimenti con le modifiche a catena rischi di buttare tutto in merda

Ok le modellerò con 2 relazioni distinte e nella tabella farmaco oltre il codice univoco chiave le 2 foreign key di tipo e regime
Grazie!!!

Cioè era diversi ordini di grandezza più semplice rispetto a quello che sembrava dovessi fare. -.-
E' ovvio che se hai una tabella con degli attributi e vuoi censirne le casistiche (esempio tuo: SESSO: M / F ) devi farne una tabella di censimento e poi usare la primary key sulla tabella padre (creando una foreign key). -.-

Quote:

---

Originally Posted by Tanek

Cioè era diversi ordini di grandezza più semplice rispetto a quello che sembrava dovessi fare. -.-
E' ovvio che se hai una tabella con degli attributi e vuoi censirne le casistiche (esempio tuo: SESSO: M / F ) devi farne una tabella di censimento e poi usare la primary key sulla tabella padre (creando una foreign key). -.-

---

Beh ma il mio poblema infatti era solo se gestirla con 2 associazioni fosse migliore o no della gestione con una associazione tripla

una relazione ternaria :O ...

Metti giu' le specifiche del DB, gran pacco che non sei altro :gha: