Estruturação de banco de dados para “atividade” e “acompanhamento” de vários objetos

5

Estou trabalhando em um aplicativo da web que opera com diferentes tipos de objetos, como usuário, perfis, páginas, etc. Todos os objetos possuem object_id exclusivos.

Quando objetos interagem, pode produzir "atividade", como postagem de usuários na página ou no perfil. A atividade pode estar relacionada a vários objetos por meio do object_id .

Os usuários também podem seguir "objetos" e precisam ver o fluxo de atividades relevantes.

Você poderia me fornecer algumas sugestões de estrutura de dados que seriam eficientes e escalonáveis? Meu objetivo é mostrar atividade limitada aos objetos que o usuário está seguindo Não estou limitado por bancos de dados relacionais.

Atualizar

Como estou recebendo conselhos sobre o ORM e como indexar as coisas, gostaria de enfatizar novamente a minha pergunta. De acordo com o meu modelo de design atual, a estrutura do banco de dados se parece com isso:

Comovocêpodever,émuitofácilimplementarumbancodedadoscomoesse.AstabelasActivityeFollowercontêmumaquantidademuitomaiorderegistrosdoqueonívelsuperior,masétolerável.

Masquandosetratadecriarumatabela"timeline", isso se torna um pesadelo. Para cada usuário, preciso referenciar todas as atividades de objeto que ele segue. Em termos de registros, fica facilmente fora de controle.

Por favor, sugira-me como alterar essa estrutura para evitar a criação de cronograma e também ser capaz de recuperar rapidamente a atividade para qualquer usuário. Obrigado.

    
por romaninsh 17.04.2012 / 15:45
fonte

5 respostas

3

Você escreveu que não está limitado a bancos de dados relacionais. Você pode considerar o uso de um banco de dados gráfico, como neo4j . As bases de dados de gráficos são particularmente adequadas para situações como a sua, onde as relações são mais importantes do que, digamos, médias e somas.

Você pode encontrar uma introdução aqui e a < href="https://github.com/thobe/social-network-workshop"> exemplo de trabalho aqui .

Uma estrutura mais complexa, mas mais eficiente, que você poderia usar é graphity .

    
por 18.06.2012 / 00:52
fonte
3

É difícil dizer sem saber muito mais, mas parece que você quer algo muito genérico. Talvez algo assim ajudasse:

activity
--------
  activity_id  - the ID of the activity
  participating_object_id - ID of a participating object
  activity_type_id - ID of the Type of activity
  activity_datetime - When this activity occurred
  data - context data of the activity

Isso permite que você tenha coisas como:

activity_id | participating_object_id | activity_type_id | date  | data
------------+-------------------------+------------------+-------+-----
1           | 2                       | 3                | ...   | this is a post
1           | 84                      | 3                | ...   | [email protected]

Isso descreve uma instância de atividade (ID # 1): um usuário (objeto # 84, dados de contexto "[email protected]") criou uma postagem em um fórum (tipo de atividade 3) cujo ID de objeto é 2, e o postagem continha o texto "este é um post".

Você provavelmente precisará expandir isso conforme sua situação exigir.

... na verdade, agora que penso nisso, a coluna data provavelmente não é necessária, já que você pode obter os dados desejados da sua base object table (seja o que for que pareça) consultando-os usando os valores em participating_object_id .

    
por 17.04.2012 / 15:57
fonte
2

Uma possibilidade é usar "herança", esp. se os objetos aos quais você se refere tiverem campos comuns. O esquema é assim:

followables
    followable_id      primary key
    -- common fields

users
    user_id            primary key references followables(followable_id)
    -- user specific fields

pages
    page_id            primary key references followables(followable_id)
    -- page specific fields

...

random_entities
    ...
    followed_id        references followables(followable_id)

Isso significa que os atributos pages e users "são" followables , têm followables 'e podem ser referenciados da mesma forma.

ORMs frequentemente criam esquemas como este para modelar a herança e lidar com a junção para você.

Não se preocupe com a ineficiência até provar que isso é um problema.

wrt. a eficiência. Escreva um script SQL simples que insira informações de teste até o número de linhas que você considera necessário. Escreva suas consultas (lembre-se, você não quer consultar sua linha do tempo inteira, você normalmente irá LIMIT suas consultas), verifique sua velocidade de execução com as coisas que você mencionou Eu estou supondo que o desempenho será satisfatório. Caso contrário, poste suas consultas e as saídas de EXPLAIN .

    
por 17.04.2012 / 21:44
fonte
1

A desnormalização será sua amiga aqui - você considerou apenas criar uma tabela de linha de tempo estática que possa ser facilmente SELECIONADA?

Eu também consideraria strongmente armazenamentos de dados não relacionais aqui - eles tendem a se encaixar bem nesse tipo de problema.

    
por 18.06.2012 / 01:13
fonte
0

Por que não usar um ORM que possa criar o esquema para você em suas aulas? Dessa forma, você pode exercitar os detalhes em um nível mais alto de abstração, deixar o ORM projetar o esquema e, em seguida, revisar o que foi feito para alterá-lo / ajustá-lo com base no desempenho.

    
por 17.04.2012 / 19:39
fonte