Qual é o padrão correto a ser usado neste caso?

5

Tenho certeza de que esse cenário surgiu antes e quero saber o que a experiência ensinou como a melhor solução.

Eu tenho um número de classes que são todas do tipo. Diga todos os objetos são "Conteúdo". Eles podem ser "Artigo" ou "Livro", por exemplo.

A razão pela qual eu quero a abstração "Content" é porque eu quero definir um número de comportamentos para todos os objetos "Content" e não ter que construir uma nova Tabela DB e 10 classes de essencialmente o mesmo código para cada tipo de " Conteúdo". Por exemplo, anexar um "Tag" ou um "Premise" a um objeto de conteúdo seria muito melhor se, digamos, eu tivesse apenas duas colunas, uma para o ContentID e outra para o TagID.

Uma solução com a qual eu brinquei é ter uma tabela de Conteúdo com um ID exclusivo e depois ter referências de chave estrangeira em todas as outras tabelas (Book, Article, etc). Isso realmente se mostrou bastante sólido, mas eu não tenho certeza disso.

Você sabe como chamar esse padrão descrito?

    
por Hanshan 13.10.2012 / 12:28
fonte

4 respostas

3

Você pode mapear a herança para as tabelas do banco de dados das seguintes maneiras,

  • Mapeie toda a hierarquia de classes para uma única tabela : Todos os atributos das classes são armazenados em uma tabela. Essa é uma boa estratégia para hierarquias de classes simples e / ou rasas, nas quais há pouca ou nenhuma sobreposição entre os tipos dentro da hierarquia .

  • Mapear cada classe concreta para sua própria tabela : Uma tabela é criada para cada classe concreta, cada tabela incluindo os atributos implementados pela classe e seus atributos herdados. Esta é uma boa estratégia quando a mudança de tipos e / ou sobreposição entre tipos é rara .

  • Mapear cada classe para sua própria tabela : criar uma tabela por classe, com uma coluna por atributos de negócios e qualquer informação de identificação necessária (bem como outras colunas necessárias para controle de concorrência e controle de versão) ). Essa é uma boa estratégia quando há sobreposição significativa entre os tipos ou quando a mudança de tipos é comum. .

Como dito, nenhuma dessas estratégias de mapeamento é ideal para todas as situações. Os especialistas recomendam começar com uma tabela por hierarquia em primeiro lugar, em seguida, se necessário, refatorar o esquema de acordo.

Do you know how to call this described pattern?

Catálogo de Padrões de Arquitetura de Aplicativos Corporativos chama isso de Mapeadores de Herança .

    
por 13.10.2012 / 13:04
fonte
2

Eu tenho me deparado com algo semelhante, com uma tabela base de Pessoas, uma abstração útil e outras tabelas, dependendo se elas são Contratante, Cliente, etc.

Para o design da tabela, se a "sub-tabela" (no seu caso, Book, Article) não puder existir sem ser Content, então eu usaria o seu design e usaria o Content_ID como a chave para Book e Article como bem.

Desde que eu uso PHP, eu tenho uma classe que lida com Content, então uma classe que estende para lidar com Books / Articles.

Se você estiver usando o banco de dados, eu recomendaria uma VIEW que SELECIONE e JOINsse as tabelas do Content-Book, e outra com o Content-Articles para facilidade de uso.

    
por 13.10.2012 / 13:02
fonte
2

Se você souber antecipadamente todo o conjunto de possíveis tipos de conteúdo, poderá usar tabela por hierarquia e colocar em uma tabela todos os livros, artigos, etc. subclasses de Conteúdo. Se, por outro lado, você puder (ou já sabe que vai) precisar de novas subclasses de Conteúdo mais tarde, eu usaria tabela-por-subclasse (como você está pensando)

Então, a questão na minha opinião é perguntar: Meu conjunto de subclasses de Conteúdo está completo ou deveria ser facilmente estendido mais tarde?

    
por 13.10.2012 / 12:59
fonte
1

Seu modelo é sólido porque você tem uma strong ideia sobre os diferentes tipos de conteúdo que deseja gerenciar (livros, artigos etc.). Ter uma tabela para cada tipo de conteúdo define os diferentes atributos. Você provavelmente pode prever mais de 90% dos tipos necessários por vários anos.

Se você colocá-los em uma tabela grande, você terá várias colunas que serão nulas. Existem alguns bancos de dados que melhoraram o tratamento de dados esparsos e podem economizar espaço. De uma perspectiva de consulta de dados, você pode incluir diferentes tipos de conteúdo com muita facilidade.

Eu vi vários sistemas (principalmente aplicativos corporativos) nos quais eles fornecem maior flexibilidade para campos definidos pelo usuário. Ao contrário da sua situação, eles não podem prever todas as entidades. Uma maneira flexível de fazer isso é com um Modelo de valor de atributo de entidade . A junção de tabelas extras e possivelmente a transposição de dados de linha em colunas, o desempenho é sacrificado pela flexibilidade do usuário. Basicamente, você quer que seu aplicativo seja orientado a programador / código ou orientado a usuário / dados?

Você pode querer considerar como você vai lidar com a pesquisa. Existem ferramentas para facilitar isso. Eu vou construir você mesmo, você tem que lidar com várias tabelas.

Talvez uma solução NoSQL deva ser considerada?

    
por 13.10.2012 / 15:59
fonte