Modello di dati delle rotaie - domanda sulle migliori pratiche

4

Sto scrivendo un'app di ricettario di Rails come esercizio di apprendimento. Ho creato una tabella per Ricette che contiene informazioni per la ricetta (nome, autore, ecc ...). Ho anche una tabella per gli ingredienti che sarà una lista degli ingredienti principali, e poi una tabella intermedia che contiene informazioni specifiche per quella combinazione di ricetta / ingrediente (ad esempio, la tabella degli ingredienti avrebbe un elenco per Cipolla, la tabella avrebbe la quantità, la tecnica (fetta, tritare, ecc ...) e qualsiasi altra cosa per una particolare ricetta).

Ad ogni modo - funziona tutto bene, ma man mano che aggiungo ingredienti al tavolo, mi rendo conto che ci sono alcune categorie di ingredienti (spezie, verdure, carne, frutta, ecc ...) e hanno pezzi diversi di info Voglio registrarli. Ad esempio, carni e verdure potrebbero avere il campo della tecnica (tritare, tagliare, tritare, ecc.) Ma le spezie potrebbero avere un campo "spice_type" da registrare se è secco o fresco. Le carni potrebbero richiedere un campo di "doneness" (ben fatto, raro, ecc.) Mentre i frutti non ...

Quindi, il punto cruciale della mia domanda - è meglio avere una grande tabella di ingredienti con campi per ogni categoria, usando solo quelli che mi servono per una particolare riga, o è meglio creare cinque tabelle, una per ogni tipo di ingrediente?

Ho iniziato a codificarlo come tabelle separate, come sembrava corretto dato che sono in possesso di campi diversi per ogni tipo, ma poi ho realizzato quanto lavoro sarebbe stato per codificare 5 x modelli, 5 x controller, 5 x visualizzazioni, ecc. ...

SO, meglio riempire tutto in un tavolo (dopotutto, sono tutti ingredienti!), ogni record lascia solo i campi non applicabili nil e rende le mie viste / etc .. dinamiche per adattarsi a qualsiasi tipo di ingrediente viene lavorato con (in sostanza nascondendo o visualizzando i campi appropriati)?

Spero che abbia senso, quando arrivo su questo sito mi trasformo in uno sciocco vagabondo;)

Grazie per l'aiuto

Aggiornamento:

Ieri stavo preparando un po 'di birra e pensavo alle mie ricette di birra sulla falsariga dell'app del mio libro di cucina, e ho capito che le ricette di birra sono un esempio migliore di quello che sto cercando di capire, quindi qui di seguito c'è la stessa domanda un paradigma diverso:

Nelle mie ricette di birra, ho tre tipi di ingredienti. C'è malto, luppolo e lievito.

Sono comuni nel senso che sono tutti ingredienti e avranno tutti alcuni attributi comuni come Nome, Marca e Prezzo. Tuttavia, ci sono attributi specifici a ciascuno che gli altri non condividono - per esempio, Malt ha un attributo SRM (essenzialmente a colori), mentre Hops ha un attributo AA (alfa acidi), e il lievito ha un attributo Flocculation.

Quindi vado STI e stendo un tavolo come questo? id, tipo, nome, marca, prezzo, srm, aa, flocculazione

Inoltre, la tabella "in-between" conterrà informazioni diverse su ciascuna. Tutti gli ingredienti avranno un attributo Amount, ma il luppolo avrà un BoilTime e i malti avranno un MashTemp, ecc ...

Quindi uso una tabella con STI e una tabella "in-between" per unirmi? Devo fare anche lo STI "in-between"?

Ho un sacco di letture da fare! :)

    
posta Jim 23.08.2011 - 23:44
fonte

3 risposte

2

Rails ha, incorporato, il concetto di Single- Eredità della tabella . Leggi su di esso e usalo, è perfetto per questa situazione.

In sostanza, ciò che fa è consentire di avere un campo tipo nella tabella che definisce letteralmente il tipo (nome classe) dell'oggetto definito nella riga. I campi che non hanno attributi corrispondenti su oggetti di un particolare tipo vengono annullati e ignorati. In altre parole: fa tutto ciò che Emmad suggerisce per te.

È una parte così fondamentale del framework che se hai un campo chiamato Type, che non sta implementando STI, allora devi aggiungere del codice per assicurarti che il framework lo sappia.

Un avvertimento: c'è un pericolo con questa tecnica di finire con una tabella con dozzine di campi che sono usati solo da pochi record. Se ciò dovesse accadere, prendi in considerazione la possibilità di prelevare alcuni di questi campi in tabelle separate. Cioè, puoi ancora avere una singola tabella principale, ma se le Spezie hanno 20 campi non usati da altri tipi, puoi memorizzarli in un'altra tabella con una relazione 1-a-1 con l'oggetto Spice.

    
risposta data 24.08.2011 - 04:16
fonte
0

Ogni tipo ha campi diversi o l'unico campo ha un significato diverso a seconda della categoria degli ingredienti? Puoi avere un campo di testo per contenere le informazioni extra (mi dispiace, non ho un nome per questo, forse una preparazione aggiuntiva?) Per l'ingrediente. Carne (tritata), pepe (appena macinato). È possibile eseguire una query in questo campo se necessario.

L'altra opzione è il collegamento a una tabella diversa per ogni categoria di ingredienti. Non ne vedo la necessità, a meno che non si desideri avere una sorta di ricerca per assicurarsi che gli utenti selezionino "Freshly Ground" anziché "Ground" o "Ground". L'altro motivo sarebbe se ogni categoria avesse diversi campi che erano diversi invece di un solo campo con significati diversi. Le opzioni su una macchina sarebbero molto diverse dalle opzioni su una moto.

    
risposta data 24.08.2011 - 01:58
fonte
0

È logico che tu combini i diversi ingredienti nella tabella 1: dovresti:

  1. hanno un ID univoco per ogni riga indipendente dal nome dell'ingrediente, ad esempio, il letterale "fruit" non è una buona chiave.

  2. definisce i campi non utilizzati come null / blank

  3. non esegui calcoli su campi non utilizzati (questo è corretto nel tuo caso)

  4. avere una colonna che indica il tipo di ingrediente

Spero che questo aiuti

    
risposta data 24.08.2011 - 01:59
fonte

Leggi altre domande sui tag