Questa situazione richiede associazioni ben definite, ereditarietà di una tabella singola o associazione polimorfica?

Question

Questa situazione richiede associazioni ben definite, ereditarietà di una tabella singola o associazione polimorfica?

#1 da (3 voti)
#2 da (3 voti)

3

Sto costruendo una web-app in cui gli utenti possono tenere traccia di chi deve soldi a chi.

Ho utenti e debiti. Dato un utente, voglio essere in grado di scoprire tutti i debiti verso altri utenti e tutti i prestiti ad altri utenti. Dato un debito, voglio essere in grado di scoprire chi sono il debitore e il creditore.

Il richiedente di questa domanda si è imbattuto in una situazione simile, ma non credo che le nostre situazioni siano abbastanza simili da giustificare l'uso della risposta principale:

link

Tratto da questa domanda, i tre paterni hanno suggerito che ci sono

associazioni ben specificate
ereditarietà di tabelle singole
associazione polimorfica

Quale modello dovrei usare nella mia situazione? Uno di questi tre, o ce n'è uno ancora più appropriato?

object-oriented-design web-applications database-design ruby-on-rails modeling

posta hhamilton 09.02.2013 - 08:50

fonte

2 risposte

3

Sembra un semplice problema su molti

Mi avvicinerei come

User 1 - * Debt

User 1 - * Loan

Quindi tutto ciò di cui hai bisogno sono le tabelle User , Debt e Loan . Le relazioni sono bidirezionali.

Dal tuo elenco di selezione si tratta di "associazioni ben specificate". Non penso che l'ereditarietà o il polimorfismo siano necessari in questa situazione.

risposta data 09.02.2013 - 09:37

fonte

Leggi altre domande sui tag object-oriented-design web-applications database-design ruby-on-rails modeling

È corretto escludere i nomi degli argomenti dai prototipi di funzioni? Pensando pragmaticamente alla scalabilità

score 3 · Accepted Answer

Consiglierei una soluzione più semplice. 2 relazioni uno-a-molti, lasciatemi spiegare:

Una tabella del debito con 2 user_ids come debitor_id e creditor_id .

come quello che un utente ha molti prestiti e molti debiti, ma ogni debito ha un solo creditore e un solo debitore. Sia i modelli che le query sono semplici e i casi che hai citato sembrano essere coperti.

Nota: sebbene sia possibile per gli stessi 2 utenti disporre di più record di prestito e debito, raccomanderei contro questo convalidando l'unicità della combinazione debitor_id, creditor_id (se tale funzionalità non è richiesta) per semplificare interrogare e avere attributi ORM più puliti.