zoro82 ha scritto:
Problema: a volte ci si ritrova con delle entità che, oltre alla chiave primaria, contengono un solo attributo. [...]
Su alcuni testi ho trovato scritto che non ha senso avere delle entità con un solo attributo (oltre ovviamente alla chiave).
Credo che a spostare l'ago della bilancia nella valutazione dipenda poi dall'uso che verrà fatto di quel campo.
Ad esempio, se la casa farmaceutica non viene inserita manualmente ma deve essere selezionabile da un elenco, ecco che sarà necessario disporre di uno "storage" in cui mettere questo elenco: in questo caso, tanto vale creare la tabella correlata delle case farmaceutiche e usare la chiave esterna per la correlazione.
Se si prevede inoltre di associare alla casa farmaceutica altri dati in futuro, andando a modificare quindi lo schema, e se non si tratta di un database "schemaless" (es.
MongoDB), l'effort di questa variazione in termini di impatto su DB e codice potrebbe essere rilevante: a questo punto, anche per questo caso, meglio creare la tabella.
Lo stesso dicasi se si intende filtrare spesso per casa farmaceutica: meglio filtrare selezionando una chiave piuttosto che il contenuto del campo.
Se nessuna delle ipotesi indicate sopra è plausibile, allora direi che è sufficiente aggiungere il campo e magari posticipare l'eventuale creazione di una tabella.
A dispetto di ciò che viene detto nei testi che hai letto, io non mi pongo generalmente il problema di quanti attributi devo assegnare a una entità, tant'è che a volte creo tabelle tipologiche composte da due campi: la chiave (ID) e un nome/descrizione.
Questo non è per dire che il testo sia sbagliato, ma credo che - soprattutto in questo ambito - molte regole non possano essere applicate come dogmi, ma è necessario valutare i benefit e i contro in base a quello che si vuole fare e quale soluzione rappresenta il migliore compromesso (trade off) prendendo in considerazione TUTTI gli aspetti.
Ciao!