Rails - per usare STI o no ... questa è la domanda

Question

Rails - per usare STI o no ... questa è la domanda

#1 da (6 voti)

7

Sei mesi fa, ho fatto una domanda sulla modellazione dei dati per la mia app, e ho ricevuto qualche consiglio che mi indicava STI (vedi Modello di dati delle rotaie - domanda sulle migliori pratiche per i dettagli).

Ci ho giocato un po ', ho funzionato un po', poi mi sono distratto e ho messo il progetto in pausa.

Ho appena iniziato a svilupparlo di nuovo da zero, con il beneficio di altri 6 mesi di programmazione / esperienza ROR, e ho ancora una volta colpito questo muro quando si tratta di modellare gli ingredienti per le mie ricette di birra.

Per dare un rapido riassunto, supponiamo di avere tre tipi di ingrediente (malto, luppolo e lievito) - ognuno di essi condivide alcuni attributi (nome, prezzo, fornitore) ma ognuno ha anche attributi specifici per quel tipo di ingrediente. Sono tutti correlati (sono tutti gli ingredienti) ma hanno un "comportamento" diverso (per esempio, i chicchi sono purè e ci sarebbe una logica per gestire ciò che non si applicherebbe al luppolo / lievito, ecc ...)

Gli ingredienti sono abbastanza diversi che sto pensando di avere solo tre tavoli separati nel db ... ma che dire dei controller? Posso utilizzare un singolo controller Ingredients per gestire i modelli separati?

Ho letto di alternative a STI (ereditarietà di tabelle di classe e ereditarietà di tabelle multiple) ma tutte le soluzioni sembrano scottanti. Ci sono alternative che mi danno la convenienza di STI (come ottenere tutti gli ingredienti, indipendentemente dal tipo, con una singola query di tabella) senza gli svantaggi (campi nulli, tabelle ingombranti quando continui ad aggiungere sottoclassi e campi, ecc.)

Scusa, so che questa domanda è un po 'confusa, ma mi sento come se non trovassi una soluzione pulita e ora sto cercando di capire quale metodo è il male minore. Sono sicuro che altri lo hanno affrontato, e mi piacerebbe sentire i pro / contro di diverse soluzioni. Grazie!

inheritance multiple-inheritance ruby-on-rails

posta Jim 21.02.2012 - 23:42

fonte

1 risposta

Leggi altre domande sui tag inheritance multiple-inheritance ruby-on-rails

Controller e ri-factoring per mantenibilità / sensibilità Serve aiuto per eliminare percorsi e variabili del codice morto dal codice sorgente C

score 6 · Accepted Answer

Mentre i campi permanentemente nulli e le grandi tabelle poco maneggevoli sono concettualmente brutte, in genere non causano alcuna reale inefficienza. Lo spazio extra utilizzato dai campi null non è una considerazione importante per la maggior parte dei sistemi e la velocità della query non sarà più lenta se si impostano bene gli indici.

I vantaggi di STI sono spesso utili (efficienza del database riducendo al minimo i join e semplicità del codice condiviso e DRYness). Quindi, se hai intenzione di utilizzare un sistema SQL tradizionale, impara semplicemente a ignorare la bruttezza concettuale e ad usare STI. Il tuo caso d'uso è ciò per cui STI è stato progettato.

Detto questo, se non sei troppo in profondità nel tuo ciclo di sviluppo perché questo progetto sia collegato al tuo sistema di database (e sembra che tu non lo sia), e sei disposto a investire un po 'di tempo nella ricerca / apprendimento, potresti davvero voler considerare un'alternativa a SQL (ce ne sono molti buoni là fuori). Attualmente l'alternativa più popolare (e la mia preferita) è MongoDB .

MongoDB è basato su documenti anziché su schemi. Ciò significa che non è così rigido su ciò che può essere memorizzato in esso. Dato che MongoDB non ha uno schema strutturato forzato, nel tuo progetto potresti avere una sola raccolta di ingredients (le "collezioni" in MongoDB sono simili alle "tabelle" nei database SQL). Ogni ingredient in questa raccolta potrebbe avere campi condivisi come definiti in una superclasse Ingredient (questi campi non sarebbero definiti nel db stesso). E le sottoclassi Malt , Hops e Yeast potrebbero avere i loro campi personalizzati (di nuovo, come definito direttamente in queste sottoclassi di modelli, non nel db stesso). Questo è esattamente quello che stai cercando - ti dà tutta la comodità di STI senza la sua bruttezza concettuale.

Bonus aggiuntivo: potresti scoprire che l'utilizzo di un sistema di database NoSQL come questo aiuterà a semplificare anche altre aree della tua app. In molti (la maggior parte?) Domini di business web comuni, NoSQL è una scelta migliore di SQL, perché i domini web tendono ad essere particolarmente ad alta intensità di documenti (quindi i documenti sono una scelta naturale per il meccanismo di archiviazione).

Riepilogo: se si è collegati all'utilizzo di un database SQL a causa dell'amministrazione o di parte della propria app che si basa su di esso, o se non si ha il tempo di investire nell'apprendimento di qualcosa di nuovo, basta andare con STI. Se non si è connessi all'utilizzo di un database SQL e si ha il tempo di imparare qualcosa di nuovo, si consiglia vivamente di passare a MongoDB o ad un altro database NoSQL basato su documenti.