Tabelle di giunzione rispetto a matrici di chiavi esterne?

Sto modellando la relazione molti-a-molti in cui si accede la relazione la maggior parte del tempo solo da una parte. È più simile a una gerarchia, a cui si accede dall'alto verso il basso e non viceversa.Tabelle di giunzione rispetto a matrici di chiavi esterne?

Survey ha e appartiene a molti Domande ha e appartiene a molti Risposte.

Entrambe le relazioni devono essere molte-a-molti perché una stessa domanda può essere riutilizzata attraverso diversi sondaggi e la stessa risposta in molte domande. Questo è un requisito.

L'implementazione M2M standard utilizza due tabelle di giunzione, surveys_questions e questions_answers. Invece, sto pensando di usare gli array interi di PostgreSQL per memorizzare question_ids in Survey e answer_ids in Domanda.

Possiamo utilizzare l'operatore ANY per interrogare tutte le righe che corrispondono alla matrice di chiavi esterne.

Come richiederemo tutti i sondaggi con le loro domande e le risposte alle domande utilizzando SQL?

Come è possibile abbinare l'ordine delle righe restituite con l'array di chiavi esterne? vale a dire. using question_ids = [1,2,3] è garantito per restituire le righe di domanda con l'ordine 1, 2, 3.

Come si esegue questa prestazione rispetto alle tabelle di giunzione (presupponendo indici appropriati, quali che siano)?

Consiglieresti questo? Ci sono delle risorse per modellare M2M in questo modo?

Aggiornamento

C'è stata una proposta di aggiungere l'integrità referenziale per array di chiavi esterne per PostgreSQL 9.3, ma non ha ottenuto incluso: http://blog.2ndquadrant.com/postgresql-9-3-development-array-element-foreign-keys/

SO domanda circa il mantenimento dell'ordine con un array chiave esterna PostgreSQL JOIN with array type with array elements order, how to implement?

fonte

2012-12-12 randomguy

si dice molti a molti, ma questo suona come uno a molti; molti a molti significherebbe che ogni sondaggio si riferisce a diverse domande e ogni domanda si riferisce a diversi sondaggi, ma suona un po 'strano, certamente, il modo in cui hai detto che "ha-molti" è normalmente sinonimo di uno a molti (molti-a -qualcuno viene solitamente chiamato "ha-and-appartiene-a-molti") – SingleNegationElimination

@TokenMacGuy: Ci scusiamo per la confusione. Le domande sono riutilizzabili attraverso sondaggi e risposte attraverso domande che rendono le relazioni molti a molti. Sostituirò la relazione con HABTM. Le tabelle di giunzione – randomguy

Utilizzare l'approccio della tabella di giunzione. Il metodo array non è abbastanza standard da dover fare domande su quanto potrebbe funzionare, mentre l'altro è completamente standard.

fonte

2012-12-12 13:09:18

possono essere notevolmente più lente rispetto agli array. vedere https://gist.github.com/joevandyk/031cf5812bd656887623 –

Sì, a volte c'è un guadagno in termini di prestazioni dal metodo array. C'è una grande domanda sul fatto che possa reggere per tutte le situazioni, naturalmente, e uno dei problemi principali è che l'aggiunta/rimozione di un nuovo collegamento richiede una modifica su una riga potenzialmente lunga (coupon, nell'esempio) piuttosto che l'inserimento/eliminazione di una singola riga e un blocco sul tavolo dei coupon. –

Concordato! Se non vuoi modificare la tabella coupon su ogni inserto, potresti avere invece una tabella coupons_products_array (coupon_id, product_ids []). Ma potrebbe essere sciocco. –

Tabelle di giunzione rispetto a matrici di chiavi esterne?

risposta

Problemi correlati