Molte relazioni multiple o multiple?

A meno che tu non comprenda e accetti pienamente le conseguenze, fare ciò in genere non è consigliabile se può essere evitato.

Le persone sono spesso tentate di usare questo modello. In teoria è possibile creare qualsiasi database con solo quattro tabelle: oggetti, proprietà, valori, collegamenti. Mentre questo tipo di modello di dati generici è molto flessibile, è anche molto inefficiente da interrogare e qualsiasi query complessa che devi scrivere contro di essa sarà molto brutta.

Fondamentalmente, ti stai privando di molti dei vantaggi che RDMS è progettato per darti.

Ecco un post che lo descrive in modo più dettagliato: link

Devo seguire Igby, questo disegno che si tende a fare, non è molto suggerito. Se hai mai lavorato con OR mapper puoi capire il problema ancora di più.

Perché sul tuo progetto avresti "entità multiple" (nel contesto mentale) dietro "una relazione n: n". Piuttosto, fai il lavoro e costruisci una nuova tabella, una tabella delle relazioni e la relazione per ogni "proprietà" (come la chiami tu) di qualsiasi entità.

Non puoi neanche integrare 1: n nel tuo progetto. Quindi creerai nuove tabelle per 1: n e nessuna per n: n sull'entità persona, che è sporca.

Questa risposta espande la risposta di Igby, con un esempio del tipo di query che può essere costruita.

Ci sono sicuramente trade-off tra i due approcci. Tuttavia, mantenere tabelle separate per diverse categorie può essere interrogato con altrettanta facilità in SQL.

SELECT UNIQUE pid FROM 
  (SELECT UNIQUE hobbyref.personid AS pid FROM hobby, hobbyref
    WHERE hobbyref.hobbyid = hobby.id AND hobby.type = 'tv')
  UNION
  (SELECT UNIQUE petref.personid AS pid FROM pet, petref
    WHERE petref.petid = pet.id AND pet.type = 'cat'
  )

(Pardon qualsiasi goffaggine nell'SQL. Potrebbe probabilmente essere espresso in modo più conciso.)

In pratica stai inventando un database su un database. Un database relazionale ha già un sistema per rappresentare le proprietà per le entità: si chiama tabelle e colonne. Creando il proprio sistema in più, si introduce un livello di complessità e allo stesso tempo si perdono molti dei vantaggi di un database relazionale. Ad esempio, questo sarà molto più lento di una query su un normale database e perderai tutti i vincoli di integrità.

Detto questo, possono essere motivi particolari per scegliere una tale architettura. Ad esempio, se desideri che gli utenti siano in grado di aggiungere dinamicamente le proprietà tramite un'interfaccia utente, potrebbe essere più facile da ottenere. Ma dovresti farlo solo se ne hai davvero bisogno e sei consapevole degli svantaggi.