Ruby on Rails database utilizzando tabelle di ricerca statiche o stringhe costanti

[EDIT] Ruby on Rails 4 enum

Rails 4 supporta enumerazioni, quindi puoi dichiarare un attributo enum in cui i valori si associano agli interi nel database, ma possono essere interrogati per nome.

class Conversation < ActiveRecord::Base
  enum status: [ :active, :archived ]
end

conversation.archived!
conversation.active? # => false
conversation.status  # => "archived"

Conversation.archived # => Relation for all archived Conversations

Conversation.statuses # => { "active" => 0, "archived" => 1 }

Rails 3 e precedenti

Potresti implementare qualcosa del genere:

USER_STATUS_VALUES = { 1 => :active, 2 => :disabled }

class UserStatus
  attr_reader :status_id

  def status
    USER_STATUS_VALUES[@status_id]
  end

  def status=(new_value)
    @status_id = USER_STATUS_VALUES.invert[new_value]
    new_value
  end
end

Lo useresti in questo modo:

my_status = UserStatus.new

my_status.status = :new
puts "status: #{my_status.status}"
puts "status_id: #{my_status.status_id}"

Restituisce:

status: new

status_id: 1

Nota: Avrei potuto usare 'active' invece di :active ma in questo caso, l'uso dei simboli è più appropriato.

should I be using strings instead of lookup tables in my ruby on rails web project (mysql and active record)?

Di solito cerco di evitare tabelle di ricerca nel mio progetto ruby on rails. Invece, tendo a memorizzare le rappresentazioni dell'utente nei file di lingua, ad esempio:

user:
  status: Status        
  status_values:
    1: Active
    2: Disabled

(O qualunque tipo di struttura tu preferisca, non sono religioso per questo.)

Quindi, nel file di modello, introduco solo le costanti di Ruby per quei valori che faccio effettivamente riferimento nel codice Ruby:

class User 
    ...
    STATUS_ACTIVE = 1

    def active?
      self.status == User::STATUS_ACTIVE
    end
end

Anche qui, non sono religioso riguardo questa particolare sintassi. Se ne hai voglia, potresti nascondere alcune di queste linee con la meta-programmazione. Le lettere "a-c-t-i-v-e" si presentano orribilmente spesso, quindi alcuni ragazzi preferiscono un approccio più DRY. ;)

Is this something specific to ruby on rails, or to dynamically typed languages?

No, ho visto entrambe le varianti (tabelle di ricerca e enumerazioni codificate) in tutti i tipi di lingue.

Or for some particular circumstances?

Questo è più simile. Ad esempio, se si dispone di un'applicazione con una possibilità significativa che questi valori cambino nel tempo; o se hai un'applicazione multi-lingua, sarebbe pazzesco dover sempre tornare al codice per cambiare qualcosa.

Ma ci sono sicuramente casi in cui non avrebbe alcun senso cambiare queste tabelle di ricerca senza cambiare anche il codice. In questo esempio, il codice deve presumibilmente sapere quando un utente è attivo o non attivo; non sarebbe logico che qualche traduttore aggiunga un terzo valore 3: maybe-active senza modificare il codice per implementare effettivamente un comportamento. In questo caso, avere una tabella separata USER_STATUS sarebbe inutile.

In breve: se "qualcuno" dovrebbe essere in grado di modificare questi valori in qualsiasi punto del tempo, questo è molto più semplice nel DB (magari con una funzionalità di "self-service" di amministratore nell'applicazione). Quindi, queste ricerche sono dati corretti della tua applicazione. Ovviamente, alcuni valori sono ovvi candidati per un DB (ad esempio, un elenco di tutti i codici Paese ISO in tutte le loro varianti).

Or is it just bad database design?

Non di per sé, come mostrato sopra.

Puoi anche utilizzare ActiveHash Gem per creare un modello statico da un file YAML / JSON.