Início / dba / Perguntas / 30040
Accepted
Jaigus
Asked: 2012-12-09 12:06:10 +0800 CST

Tópicos e posts representados por uma tabela ou duas?

  • 772

No momento, estou construindo um componente de fórum para um aplicativo maior e estou considerando abordagens diferentes para certas partes do esquema do banco de dados. Em particular, estou pensando em representar tópicos e postagens em uma única tabela. Embora eu veja os tópicos e postagens praticamente iguais, fico um pouco apreensivo, pois isso pode tornar as coisas menos flexíveis no futuro.

Quando os tópicos de um determinado fórum são consultados, o título e a primeira postagem serão mostrados, bem como algumas informações do usuário (basicamente o nome e o avatar). Nesta aplicação, existem vários atributos que são usados ​​por tópicos e postagens, exceto por visualizações e respostas; e talvez título e forum_id(forum_id porque isso significaria potencialmente centenas de registros precisam ser afetados se um tópico for alterado para outro fórum em vez de alterar o atributo forum_id na relação do tópico).

As tabelas se parecem com o que tenho abaixo aqui:

TOPIC            POST           
topic_id         poster_id   
forum_id         topic_id 
poster_id        content 
title            upvote
views            dnvote
replies          closed
post_id          deleted
                 last_edited
                 last_editor
                 parent_id
                 content
                 post_id

Fazendo dessa forma, usando herança de tabela, gerar as postagens no tópico exigiria uma junção de 4 tabelas via TOPIC, POST, USER e TOPIC_TYPE.

Por outro lado, se eu decidir usar a abordagem de tabela única, devo simplesmente deixar os atributos views, answers, title e forum_id como nulos se o topic_type for uma postagem normal? (topic_type faz referência a um ícone apropriado para o tipo de tópico exibido e será usado para estatísticas e etc.)

database-design performance

1 respostas

  1. Best Answer
    Geralmente...

    Uma regra prática: não pré-otimize para desempenho . Acho que muitos desenvolvedores assumem que as junções são ineficientes e não confiam no DBMS para fazer o que foi criado para fazer.

    Comece com um projeto devidamente normalizado. Certifique-se de que seus índices e consultas sejam otimizados para seu equilíbrio específico de leituras e gravações.

    Se e quando você começar a achar que o desempenho não consegue acompanhar o melhor hardware que você pode pagar, comece a pensar em desnormalizar.

    Se você desnormalizar cedo, estará apenas se preparando para dores de cabeça de manutenção no futuro.

    Mais especificamente...

    Olhando para os layouts de mesa sugeridos, sugiro que você esteja tentando TOPICfazer muito. Qualquer coisa que possa aparecer em POST(por exemplo poster_id) quase certamente não pertence a TOPIC. Eu sugiro que você ajuste seu pensamento um pouco. Tenho a impressão de que você está pensando muito sobre como os tópicos e postagens serão exibidos na página. Isso pode estar levando você a pensar nos tópicos como um pequeno superconjunto de postagens, enquanto eles provavelmente são mais como cabeçalhos de assunto. O fato de você planejar exibir a primeira postagem em cada cabeçalho de assunto junto com o cabeçalho não é um bom motivo para misturar postagens e cabeçalhos.

    Acho que você também pode querer repensar algumas de suas colunas totais cumulativas. Pensamentos como votos positivos e negativos podem precisar ser rastreados em suas próprias tabelas. Você pode precisar fazer isso para evitar que as pessoas votem a favor ou contra repetidamente e para permitir que as pessoas rescindam seus votos. Da mesma forma, você pode querer conhecer todos os editores, não apenas o último editor.

    • 5

relate perguntas