[Resolvido] Desativar cliente depois de 1 mes

voce pode fazer com que a cron execute um arquivo php com estas verficações diariamente e inativa caso nao acusado o pagamento

Cron é uma boa alternativa. Mas sempre deve pensar que, conforme a quantidade de dados, não é viável executar uma ação todos os dias. 99,9% das crons são realizadas durante a madrugada para evitar consumo de processamento em horário de pico. O restante (0,01%), são crons que não podem ser colocadas durante a madrugada pois já existirem outras.... '-'

Outra alternativa, pode ser você usar por sql.

Utilize um campo data_pagamento.

Então:

SELECT * FROM cliente WHERE data_pagamento >= ( CURRENT_DATE - INTERVAL 30 DAY );

Assim só retornará os clientes que possuem a data de pagamento maior que a de 30 dias atras. É uma lógica, ou outra:

SELECT * FROM cliente WHERE ( data_pagamento + INTERVAL 30 DAY ) >= CURRENT_DATE;

Clientes que possuam data de pagamento + 30 dias, maior que a data atual. As duas possuem o mesmo propósito.

Mais fácil e menos "consumo de recurso" em uma cron diária. Dependendo da quantidade de registros, uma pode ser mais performática que a outra.

Mais fácil e menos "consumo de recurso" em uma cron diária. Dependendo da quantidade de registros, uma pode ser mais performática que a outra.

mais creio que utilizar uma cron ainda é a solução por que do jeito que você esta propondo é só para retornar o cliente em uma administração.

pelo que entendi do projeto dele seria mais ou menos assim, não pagou não consegue mais entrar no sistema.

então o cron fica sendo uma boa opção.

a não ser que ele resolva filtrar por intervalo como você citou e quando recuperar os valores antes de iniciar a session verifica se esta pago e se não tiver retorna para página de login

agradeço a todos que mim ajudaram, mas é o seguinte:

os clientes nao entram no sistema, eles somente se cadastram no site e quando é cadastrado ele fica com status 0 = desativado, ai depois, quando ele pagar o valor, os administradores entram no sistema principal e ativam o usuario que pagou, mudando o status de 0 para 1, ou seja ativado , mas depois de 1 mes se o cliente nao pagar novamente, automatecamente o sistema volta o status dele para 0!

acho que ta bem explicado, brigadao ai pessoal!

a não ser que ele resolva filtrar por intervalo

Exato.

Não vejo problemas nisso. Se ele busca por um campo:

'SELECT * FROM cliente WHERE status = 1;';

Ele só deve mudar esse campo:

'SELECT * FROM cliente WHERE ( data_pagamento + INTERVAL 30 DAY ) >= CURRENT_DATE;';

Com sql, ela ainda pode verificar exatamente 1 mês (casos de meses com 28,29 e 31 dias ). Basta alterar de 30 dias para 1 mês.

'SELECT * FROM cliente WHERE ( data_pagamento + INTERVAL 1 MONTH ) >= CURRENT_DATE;';

Pode até criar uma função.

'SELECT * FROM cliente WHERE is_ativo( data_pagamento ) = true;';

Fica até mais fácil que criar uma cron. Basta, apenas, olhar o problema por outro ângulo. Já que ele desativa o cliente após 30 dias, é implícito que ele possua um campo de data de pagamento. Se não houver esse campo, haja planilha no excel ou uma p*** memória.

>
Fica até mais fácil que criar uma cron. Basta, apenas, olhar o problema por outro ângulo.

eu achava que o parceiro teria um sistema para logar, mais como é só para administração o jeito que você informou é o mais adequado realmente não há por que ficar fazendo requisição a cada tempo.

cara, acho que entendi :)

mas vou fazer disso, quando o administrador for listar os usuarios ativos, que ja pagaram, vou executar:

'SELECT * FROM cliente WHERE ( data_pagamento + INTERVAL 1 MONTH ) <= CURRENT_DATE AND ativo = 1';

que vai trazer os registros ativos mas que ja venceu o mes, pego o ID deles e dou um update na situações dele para 0 = desativado!

entao se toda vez que for listar, executa e altera a situação se estiver vencido de pagamento, vou tentar aqui , logo volto para dá a resposta, obrigado!

[...]quando o administrador for listar os usuarios ativos[...][...]toda vez que for listar, executa e altera a situação se estiver vencido de pagamento[...]

Não seria uma prática aconselhável. Pois se o administrador ficar um dia sem entrar no sistema, não vai alterar. Então o cliente continuará como ativo.

Sugiro você ignorar a coluna ativo, e se basear somente pela data.

>
Não seria uma prática aconselhável. Pois se o administrador ficar um dia sem entrar no sistema, não vai alterar. Então o cliente continuará como ativo.

Sugiro você ignorar a coluna ativo, e se basear somente pela data.

nao sei se pode no forum, mas ...

cara tem como mim adiciona no email?

por que nao entendi direito, o que voce disse, obrigado/!

Na verdade, responderei por aqui mesmo, pois o conhecimento pode ser muito útil futuramente.

Vamos lá.

Suponha que você possua esses dois clientes na sua tabela.

nome | data_pagamento | ativo
Gabriel | 2012-04-15 | 1
Victor | 2012-04-16 | 0

Veja que. Eu, Gabriel, estou ativo no sistema, pois minha flag 'ativo' está com o valor 1(TRUE). Entretanto, já faz mais de um mês que eu paguei. E você, Victor, não está ativo, pois sua flag está com o valor 0(FALSE).

Mas isso está errado!!!

E qual o porque que eu coloquei em negrito? Segue um questionamento para fazer a si mesmo.

P: Mas qual é a regra de negócio para um cliente estar ativo? O que determina se um cliente deve estar ativo no sistema?

R: Possuir a data de pagamento inferior a 1 mês.

Então, sua regra de negócio diz que: "o cliente só está ativo quando a data de pagamento for inferior a um mês'. Isso inclui a data de hoje. Assim, contando os dias, eu estaria inativo e você ativo. Certo?

E você vai me falar o seguinte: E como faz isso? Terá de alterar sempre as flags?? Todos os dias???? Mas é muito trabalho!!

Agora vamos ao problema real. Já que definimos a regra de negócio, vamos trabalhar só com ela.

Segue a nova tabela.

nome | data_pagamento
Gabriel | 2012-04-15
Victor | 2012-04-16

Veja bem que eu removi a coluna ativo. Pois ela é desnecessária conforme o que foi passado do seu sistema.

Agora você tem a seguinte regra. O cliente está ativo quando, e somente quando, a data de pagamento for igual ou inferior a um mês.

Eu suponho que, atualmente, você retorna todos os clientes ativos da seguinte forma:

'SELECT * FROM cliente WHERE ativo = 1';

Um cliente, está ativo, no seu sistema, porque possui a flag 'ativo' com o valor 1 (TRUE).

Mas, conforme sua regra de negócio acima mencionada, seu cliente está ativo quando, e somente quando, o último pagamento dele for inferior a um mês. Certo?

Agora adaptando para a sua realidade e para sua regra de negócio. Sua consulta seria:

'SELECT * FROM cliente WHERE data_pagamento + INTERVAL 1 MONTH ) <= CURRENT_DATE';

Essa consulta irá retornar, realmente e somente, os clientes ativos, conforme a sua regra de negócio.

Assim, não há necessidade de você buscar o cliente quando a flag 'ativo' for TRUE. E sim, pela real regra de negócio do seu sistema. Quando a data de pagamento for inferior a um mês.

Entendeu o porque de não haver necessidade alguma você utilize a flag 'ativo'?

>
Na verdade, responderei por aqui mesmo, pois o conhecimento pode ser muito útil futuramente.

Vamos lá.

Suponha que você possua esses dois clientes na sua tabela.

nome | data_pagamento | ativo
Gabriel | 2012-04-15 | 1
Victor | 2012-04-16 | 0

Veja que. Eu, Gabriel, estou ativo no sistema, pois minha flag 'ativo' está com o valor 1(TRUE). Entretanto, já faz mais de um mês que eu paguei. E você, Victor, não está ativo, pois sua flag está com o valor 0(FALSE).

Mas isso está errado!!!

E qual o porque que eu coloquei em negrito? Segue um questionamento para fazer a si mesmo.

P: Mas qual é a regra de negócio para um cliente estar ativo? O que determina se um cliente deve estar ativo no sistema?

R: Possuir a data de pagamento inferior a 1 mês.

Então, sua regra de negócio diz que: "o cliente só está ativo quando a data de pagamento for inferior a um mês'. Isso inclui a data de hoje. Assim, contando os dias, eu estaria inativo e você ativo. Certo?

E você vai me falar o seguinte: E como faz isso? Terá de alterar sempre as flags?? Todos os dias???? Mas é muito trabalho!!

Agora vamos ao problema real. Já que definimos a regra de negócio, vamos trabalhar só com ela.

Segue a nova tabela.

nome | data_pagamento
Gabriel | 2012-04-15
Victor | 2012-04-16

Veja bem que eu removi a coluna ativo. Pois ela é desnecessária conforme o que foi passado do seu sistema.

Agora você tem a seguinte regra. O cliente está ativo quando, e somente quando, a data de pagamento for igual ou inferior a um mês.

Eu suponho que, atualmente, você retorna todos os clientes ativos da seguinte forma:

'SELECT * FROM cliente WHERE ativo = 1';

Um cliente, está ativo, no seu sistema, porque possui a flag 'ativo' com o valor 1 (TRUE).

Mas, conforme sua regra de negócio acima mencionada, seu cliente está ativo quando, e somente quando, o último pagamento dele for inferior a um mês. Certo?

Agora adaptando para a sua realidade e para sua regra de negócio. Sua consulta seria:

'SELECT * FROM cliente WHERE data_pagamento + INTERVAL 1 MONTH ) <= CURRENT_DATE';

Essa consulta irá retornar, realmente e somente, os clientes ativos, conforme a sua regra de negócio.

Assim, não há necessidade de você buscar o cliente quando a flag 'ativo' for TRUE. E sim, pela real regra de negócio do seu sistema. Quando a data de pagamento for inferior a um mês.

Entendeu o porque de não haver necessidade alguma você utilize a flag 'ativo'?

cara, sinceramente, mim deu uma aula agora, ta de parabens, aprendi!

valeu cara obrigadão!

Ótimo! Essa é a ideia do fórum. E como falei anteriormente, precisa-se ver o problema de ângulos diferentes.

Existe inúmeras soluções para um mesmo problema. Nem sempre há um melhor. Só aquele que se 'adapta' melhor como solução do problema.

>
Ótimo! Essa é a ideia do fórum. E como falei anteriormente, precisa-se ver o problema de ângulos diferentes.

Existe inúmeras soluções para um mesmo problema. Nem sempre há um melhor. Só aquele que se 'adapta' melhor como solução do problema.

só para completar a excelente explicação do nosso amigo Gabriel.

Nem sempre o problema esta no código mais sim na ideia, em como você aplica tudo isso então é sempre bom você fazer um briefing do seu projeto, mesmo sendo o projeto mais simples do mundo eu lhe garanto que vai te poupar um tempo.

[...]eu lhe garanto que vai te poupar um tempo

Exato! Além de futuras dores de cabeça.

Valeu pessoal, obrigadão!