1. Você precisa ter uma conexão permanente com o banco, só para monitorar as notificações. No nosso caso, tínhamos cerca de 60 clientes. Isto significava que o banco estava sempre com pelo menos 60 conexões. Agora some isto às conexões utilizadas pelos comandos SQL, e você facilmente chega a uma média de mais de 100 conexões. Se você for usar com mais clientes então... imagine os recursos consumidos. Principalmente consumo de memória do servidor, que poderia ser usada de verdade, por consultas por exemplo.
2. Falhas de recebimento de notificações. Eventualmente estas conexões podem ser mortas pelo postgres: falta de atividade, falta de recursos, etc... Isto significa que você terá que ficar testando o status da conexão.
3. Impossibilidade de realizar tarefas de manutenção como "Vacuum", "alter table", etc. Comandos de manutenção de uma tabela (como criar um novo campo) sempre esperam que todas as conexões que realizam alguma atividade nesta tabela acabem. Isto é, se você sempre tiver conexões monitorando a tabela "X", você precisará derrubar estas conexões antes de fazer um "vacuum" ou um "alter table". Caso contrário, o comando causará deadlocks (nem seu comando, nem os dos clientes irão funcionar).
4. Criação de um processo em segundo plano. Você terá que criar um processo, apenas para controlar a atividade das notificações (mas você também terá que fazer isto se usar sockets).
5. Dependência do banco. Isto não chega a ser um grande problema, mas suponha que seus clientes queiram usar o Oracle. Neste caso você terá que mudar os fontes, o que não seria necessário se você usasse sockets.
----- Entre as vantagens eu destacaria:1. Quem gravar na tabela não precisa enviar pacotes via rede para seus clientes. Isto significa que você pode monitorar atividades de outros sistemas. Por exemplo: você pode querer receber uma notificação de lançamento de uma baixa no Microsiga (um ERP que usa o postgresql).
-----Bem, nós botamos na balança aquilo que era desvantagem e o que era vantajoso (de acordo com a nossa forma de trabalhar). No fim, acabamos decidindo que o cliente que escrevia na tabela deveria avisar o cliente que monitorava esta tabela (via TCP/IP). Você também deverá ver quais suas necessidades e o que é mais prioritário para você.
Sds, Daniel Loureiro. Cristiano Panvel escreveu:
Beleza, Meu cenário é mais ou menos o seguinte: Estou programando em Qt com C++, e a aplicação será um atendimento de chamadas crítico, então por exemplo um usúario X inseriu uma chamada, no banco de dados imediatamente ela deve aparecer, para os outros 50 atendentes. Mais todos poderam inserir e encerrar a chamada, entendeu. Eu poderia usar sockets para isso ou RPC mais sou novo em Qt não gostaria de me arriscar tanto. E não gostaria de ter que ficar tando refresh na tela a cada segundo isso fica muito feio, somente quando for necessário. Qual é a sugestão para o cenário. Cris
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Grupo de Usuários do PostgreSQL no Brasil Antes de perguntar consulte o manual http://pgdocptbr.sourceforge.net/ Para editar suas opções ou sair da lista acesse a página da lista em: http://pgfoundry.org/mailman/listinfo/brasil-usuarios
