É este um uso legítimo do Rails' Herança de Tabela Única?

Question

Acabei de ler o post do blog Chad Fowler sobre 20 Rails Desenvolvimento No-Nos. Em Herança de Tabela Única ele comenta:

O armazenamento de uma coluna chamada “tipo” que detém um nome de classe é um indicador muito bom que algo suspeito está acontecendo. É suspeito mas nem sempre ruim. Creio, porém, que a qualquer momento você usá-lo você deve perguntar a si mesmo mais de uma vez se é a solução certa. Bancos de dados não fazem o que fazem melhor, bem como quando você tem um monte de STI e associações polimórficas.

Eu estou escrevendo um aplicativo de blog e eu estou pensando em usar STI pelos comentários que podem ser feitas em um post e para as mensagens de contato que os visitantes podem postar, se quiserem entrar em contato comigo. Meu modelo Message vai herdar meu modelo Comment. Eles ambos os atributos comuns ação, exceto que Message terá um campo subject extra. Outra semelhança é que ambos serão submetidos ao Akismet para verificação de spam.

Ao invés de apenas perguntar-me mais de uma vez se é a solução certa como Chad sugere, eu pensei que iria obter algumas opiniões de especialistas Stack Overflow bem! Faz o que eu estou propondo soa como um bom ajuste para STI?

Answer 1

Eu usei STI um número de vezes. Considere um CMS que pode ter página, NewsItem, BlogItem etc.

Eles poderiam cada descida de uma classe comum que em herda sua vez de ActiveRecord. A tabela para cada um seria o mesmo (título, corpo, etiquetas, published_at), mas cada modelo podem ter diferentes associações, ou estados diferentes, ou um fluxo de trabalho diferente para que cada um tem um código personalizado em sua própria classe. No entanto, todos eles compartilham uma mesa comum e classe pai. Ele também permite que eu use a classe pai para fazer uma pesquisa de classe cruz e ter o array resultante de registros digitar automaticamente elenco.

Existem outras maneiras de lidar com isso e talvez não o melhor exemplo, mas certamente há momentos em que STI é útil para situações em que o comportamento dos objetos podem ser diferentes, mas persistiu estado é o mesmo. Claro que você tem que ter certeza que isso também é verdade no futuro.

Em seus comentários de caso e mensagens de contato são diferentes. Parece que não há nenhum benefício por tê-los na mesma tabela. Talvez colocar o código compartilhado em uma classe pai ou melhor ainda em um módulo em / lib.