Persistência de dados, padrões e abordagens

Question

Persistência de dados, padrões e abordagens

#1 resposta do (3 votos)
#2 resposta do (2 votos)
#3 resposta do (1 votos)

5

A persistência de dados tornou-se realmente um problema para mim, especialmente quanto tempo manter a conectividade do banco de dados e quantas conexões são viáveis para uma determinada solicitação. Eu tenho usado o .NET; no entanto, esta é uma questão genérica relacionada a qualquer lanaguage. A partir de uma perspectiva .NET, estou me conectando ao banco de dados usando o EF4 e, para uma determinada página do site, posso criar 6 conexões por solicitação para renderizar uma página. A página pode consistir em notícias, preços de ações, etc, e precisa ser atualizada constantemente.

Recentemente, analisei a abordagem de unidade de trabalho (por exemplo, por solicitação). Então, basicamente, quando uma solicitação é iniciada, se necessário, uma conexão com o banco de dados é aberta e destruída no final da solicitação. Não estou convencido de que seja a melhor abordagem até agora. Estou à procura de opiniões e experiências sobre isso.

c#

por Nickz 18.05.2011 / 08:14

fonte

3 respostas

3

Muitos dos bancos de dados lá fora têm um limite rígido no número de conexões - ou seja, se você atribuir um número x de conexões por solicitação, você estará atingindo um teto muito em breve. Você deve examinar os objetos db de pooling / caching de conexão localmente ou em servidores de cache, etc. Também a conexão db Init / destroy é uma operação dispendiosa. Atenha-se ao pooling e permita que um proxy gerencie isso para você em segundo plano.

Esta pode não ser uma opinião popular, mas eu também não sou um grande fã de se conectar diretamente com os bancos de dados dos servidores da Web. Uma maneira de resolver isso é adicionando camadas adicionais de serviço entre as quais você pode garantir que o banco de dados seja abstraído. Dessa forma, você não precisa se preocupar com dimensionamento independente / alteração de camadas de cache / particionamento / adição de cache posteriormente.

por 18.05.2011 / 10:46

fonte

2

Eu uso um pool de conexões. Toda vez que eu termino com um, eu jogo em uma pilha. Se eu precisar de um, começo a sair da pilha até encontrar uma conexão ativa (conexão que não atingiu o tempo limite enquanto estava na fila). Eu uso essa abordagem porque tenho muitos pedidos / segundo e minhas conexões são recicladas muito rapidamente. Eles raramente têm tempo suficiente para tempo limite dentro da pilha. Claro que você precisará sincronizar a pilha. Eu uso Redis como um banco de dados, mas suponho que funciona para qualquer tipo de conexão que tenha um soquete subjacente.

por 18.05.2011 / 08:33

fonte

Tags c#

Quando existem várias equipes scrum, com que frequência o 'scrum de scrums' deve se reunir e quem deve participar? Job Scheduling, procedimentos armazenados

score 1 · Accepted Answer

Minha filosofia geral sempre foi que as camadas de acesso a dados devem ser projetadas para serem desconectadas e sem estado. Em outras palavras, você tem uma camada de banco de dados responsável por buscar diferentes tipos de dados e retorná-los e imediatamente desconectar a conexão (devolvê-los ao pool)

Se você tiver coisas como paginação, ele deve ser implementado no nível do banco de dados com as entradas de sp tomando nr por página e página para buscar, assim você não precisa manter nada persistente na memória entre as solicitações.