Projeto DB: mais tabelas vs menos mesas

O problema é semelhante à questão de quão profundo sua hierarquia deve estar em um design OO.

Uma abordagem simples em termos OO seria ter uma classe base Poste as crianças para BlogPost, ForumPoste assim por diante. Commentou poderia ser um filho de Postou sua própria hierarquia, dependendo de suas necessidades.

Então como é que isto vai ser mapeado para DB tabelas é uma questão totalmente diferente. Este ensaio clássico por Scott Ambler lida com as diferentes estratégias de mapeamento e explica suas vantagens e desvantagens de uma forma bastante detalhada.

Geralmente, a vida será mais fácil se você pode ter todas as mensagens em uma tabela:

• menos se junta para executar
• menos mesas para manter
• atributos comuns não são repetidos entre tabelas
• código mais genérico

No entanto, você pode executar em algumas questões:

• se cada subtipo tem um monte de seus próprios atributos, você pode acabar com muitas colunas - talvez demais para o seu DBMS
• se um subtipo tem um atributo (por exemplo, uma imagem armazenada) que é caro para seu DBMS para manter mesmo quando não utilizados, você pode não querer essa coluna em todas as linhas

Se você correr até um problema, você pode criar uma nova tabela apenas para os atributos específicos de que o pós subtipo - por exemplo:

create table posts (post_id number primary key, 
                    post_date date,
                    post_title ...); /* All the common attributes */

create table photo_post (post_id references posts, photograph ...);

Em muitos casos, nenhum desses problemas surgem e uma tabela única para todos será suficiente.

Eu não consigo pensar em nenhum mérito na criação de uma tabela distinta para cada subtipo.