Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Olá Pessoal,
Gostaria de receber dicas e saber um pouco sobre as experiências de quem já passou por isso.
Vou tentar ser o mais transparente possível:
Estou trabalhando em um sistema que precisa fazer uma escolha aleatória de uma lista com mais de 1.000 (hum mil) registros.
Tipo: Quando um usuário se loga ao sistema, dos 1.000 registros o sistema escolhe 1 (um) e deve fixar esse registro pra esse usuário logado. Este registro não pode mais mudar mesmo o usuário se logando novamente. Deve permanecer fixo e inalterável pra esse usuário.
Minha dificuldade estar sendo os acessos via mobile (celulares e Smartphone). Não descobri ainda o que estar acontecendo, pois, quando as pessoas se logam o sistema escolhe um registro, porém, quando a pessoa sai do sistema e se loga novamente o registro estar mudando onde deveria permanecer fixo.
Os acessos via desktop não acontece isso.
Gostaria de receber dicas e/ou sugestões. O que você sugeria? O sistema deve fixar esse registro no momento do login?? Ou após o login na abertura do painel administrativo?? Qual o melhor momento para se definir essa fixação?? Alguém já passou por isso na versão mobile??
Um forte abraço.
>
Grave o registro numa tabela com id do user , data e numero do registro no primeiro acesso ,
No primeiro acesso do dia veja se o registro existe , se existe use este senão crie um novo
Rode um EVENT todo dia as 0h para excluir os registros do dia anterior.
Então amigo, basicamente o sistema faz isso. Só que até gravar o registro o sistema precisa fazer uma série de querys até ter certeza que que fato o registro estar disponível.
O que ocorre é que o acesso por celulares, às vezes, é bem lento e antes do sistema concluir essa série de querys o registro acaba sendo utilizado por uma pesquisa mais rápida de, talvez, um computador. Eu preciso executar algo que evite esse atrito entre o mobile e o desktop. Não sei se consegui ser claro na explicação.
... o acesso por celulares, às vezes, é bem lento ... Não sei se consegui ser claro na explicação. ...
Creio que sim
O limite de 1.000 (hum mil) registros tem algum motivo ?
Não seria possível vincular apenas o registro ao usuário , um indicador do tipo ativo/inativo ?
A escolha no lugar de aleatória não poderia ser sequencial (1,2,3,4,5....1000,1,2 ...) ?
>
Creio que sim
O limite de 1.000 (hum mil) registros tem algum motivo ?
Não seria possível vincular apenas o registro ao usuário , um indicador do tipo ativo/inativo ?
A escolha no lugar de aleatória não poderia ser sequencial (1,2,3,4,5....1000,1,2 ...) ?
Eu citei 1.000 apenas como uma base, mais chega a ser bem mais que isso. A escolha é aleatória pois nem todos os registros obedecem aos critérios.
Até tem como vincular; o problema é que até chegar a esse vínculo é preciso passar por um sequencia de querys. E quando alguém acessa pelo celular, o sistema abre o processo e antes de fechar esse processo algum acesso mais rápido acaba, digamos, tomando aquele registro em análise dentro do processo.
Meu problema realmente estar sendo os acessos por celulares. E mais de 80% das pessoas no sistema acessam pelo celular.
Não consigo ver motivos para colisão, o limite é físico ?
Qual a razão de vincular um usuário à um registro aleatório ?
O usuario se loga no Sistema , o registro da tabela muda um campo status de inativo para ativo ,
O usuario se desloga no Sistema , o registro da tabela muda um campo status de ativo para inativo ,
Regras que permitam ou não o acesso ao sistema como adimplência , vigência poderiam ater rodar previamente e deixar a posição atualizada.
A sequencia de sql´s poderia em tese estar em procedure do BD , em tese a App bastaria fazer uma chamada
>
Não consigo ver motivos para colisão, o limite é físico ?
Qual a razão de vincular um usuário à um registro aleatório ?
....
....
A sequencia de sql´s poderia em tese estar em procedure do BD , em tese a App bastaria fazer uma chamada
Entendo. As sequencias estão em procedures.
Meu problema são os acessos via celulares. Imagine 200 usuários se logando ao mesmo tempo através de celulares com conexões lentas e outros se logando por computadores. De alguma forma isso estar deixando o sistema confuso e gerando essas colisões de informações.
O que preciso resolver é a questão de que uma lentidão não interfira na fixação desses registros. Preciso definir melhor o momento exato do sistema fazer essa seleção e fixação.
Em tese, se o processo roda todo no servidor, do início ao fim e sem pausas, a "lentidão" do mobile não deveria afetá-lo; se é o servidor quem executa o processo, ele não depende da conexão do usuário. Então a partir do momento que o servidor receber a requisição, mesmo que a conexão do usuário seja lenta, o processo vai rodar dependendo da velocidade do seu servidor - a não ser que no meio do processo ele pare para consultar alguma informação que está no dispositivo do usuário.
Em que momento você define que o registro está "em uso"? No fim? Talvez você possa adicionar um marcador no registro bem no início do processo para indicar que aquele registro está "reservado", e sempre que for iniciar um novo processo (ex: para outros usuários) você deixa os registros "reservados" e "em uso" de fora do "sorteio". E aí no fim do processo, ou você define o registro como "em uso" (se deu tudo certo) ou então remove o marcado "reservado" para que ele possa ser usado por outra pessoa...
Em que momento você define que o registro está "em uso"? No fim? Talvez você possa adicionar um marcador no registro bem no início do processo para indicar que aquele registro está "reservado", e sempre que for iniciar um novo processo (ex: para outros usuários) você deixa os registros "reservados" e "em uso" de fora do "sorteio". E aí no fim do processo, ou você define o registro como "em uso" (se deu tudo certo) ou então remove o marcado "reservado" para que ele possa ser usado por outra pessoa...
Humm. Entendi sua sugestão. Muito válida. Estou refazendo o procedimento e estudando cada possibilidade.
Grave o registro numa tabela com id do user , data e numero do registro no primeiro acesso ,
No primeiro acesso do dia veja se o registro existe , se existe use este senão crie um novo
Rode um EVENT todo dia as 0h para excluir os registros do dia anterior.