Felipe, desculpe se pareci "arrogante". Não foi a intensão; Minha sugestão na verdade trata-se de uma "copia" do sistema ON rodando em uma rede interna, aqui denominado esta copia como OFF.
Esta solução que sugeri já implementei em um projeto que trabalhei com grande sucesso. Tratava-se de um sistemas e pedidos, onde o sistema era acessado online. Mas a internet erá bastante instável e cai com frequência. Então se por acaso a internet cai-se, o cliente não podia deixar de lançar novos pedidos (no caso do nosso colega, inscrições) ou mesmo alterar os pedidos já existentes. Para isto tínhamos uma copia do sistema na rede interna que era sincronizado em tempo real (via replicação direta no MySQL). Então suponde que a internet sai-se fora do ar, os funcionários simplesmente passavam a acessar o sistema no IP de contingencia (ip rede interna/servidor interno) e quando o problema com a internet fosse sanado um responsável acessava no servidor interno e rodava uma rotina que sincronizava os dados no servidor central. A diferença é que criamos um webService para receber estes pedidos e atualizá-los. Atenciosamente, -- Gladyston Batista Belo Horizonte-MG Em 6 de junho de 2012 14:26, felipe bastos <[email protected]> escreveu: > Calma Gladyston .. a menos que vc faca parte da equipe do Paulo, nao > sabemos as regras de negocio que o cliente dele solicitou. > > Por exemplo .. pra mim tanto o banco ON quanto o OFF sao oficiais .. e > ambos precisariam estar atualizados. > > Do jeito q falou, seriam 2 tipos de sistema OFF .. um para o escritorio do > cliente e outro para o evento. Com o sistema ON ficariam 3 sistemas. > > Em uma modelagem negerica .. ele pode criar quantos off quiser > > A sua sugestao .. pode nao servir para ele. > Em 06/06/2012 11:50, "Gladyston Batista" <[email protected]> escreveu: > > Paulo, a tabela de inscrições com certeza terá os três campos: id >> (auto_incremento), id_evento e id_usuario. >> >> id -> chave primaria auto_increment; >> id_evento -> chave estrangerá do evento >> id_usuario -> chave estrangerá do carinha que se matriculou no evento >> >> >> Crie uma rotina no "OFF" para sincronizar os dados. Como? >> >> 1. OFF conecta no ON (solicitar/configurar dados para conexão) >> 2. OFF usando a chave (id_evento, id_usuario) verifica se registro >> existe no ON >> 3. Caso registro exista, atualize os campos necessários >> 4. Caso registro não exista, trata-se de uma nova inscrição -> insere >> o registro e seus filhos na tabela de inscrições (pegando o id ultimo+1). >> 5. fim!!!! >> >> >> Qual a complicação? Este banco OFF é apenas temporário enquanto o evento >> estiver ocorrendo. O banco official será sempre o ON. >> >> >> Em 6 de junho de 2012 10:20, Paulo Duarte >> <[email protected]>escreveu: >> >>> Então... >>> Respondendo a algumas perguntas: >>> 1) Servidor online fica sempre online (cuida dos eventos q tem acesso a >>> internet) >>> 2) Servidor local fica só local e para um evento específico. Tanto >>> consulta os dados prévios daquele evento como grava novos dados. >>> 3) Qdo for offline, não tem acesso a internet. Somente qdo o evento >>> acabar. >>> 4) Precisamos do admin local (off) e online, pois o off acontece no >>> local do evento, é uma pessoa usando e no online é acessado do escritório >>> do cliente e os funcionarios ficam acessando. >>> >>> >>> em teoria eu também achei simples... Qdo comecei a analisar a aplicação >>> comecei a me perguntar: >>> Exemplo: >>> - Tenho uma tabela de inscrições que é genérica para todo o sistema, >>> guarda os dados do inscrito e o id do evento q ele pertence. >>> - Essa tabela vai se incrementando conforme novas inscrições vão sendo >>> feitas independente do evento. >>> >>> Quando levo um evento para o offline (faço uma rotina q exporta todos os >>> dados do evento, até aí tranquilo) não vejo problema. >>> Aí utilizo o evento off, cadastrando novas inscrições pro evento... a >>> tabela vai se incrementando. >>> No online estão acontecendo também novas inscrições para outro evento, >>> mais está incrementando a mesma tabela. >>> >>> Aí quando vou sincronizar as duas, vou ter dados diferentes como mesmo >>> ID na tabela de inscrições, de eventos diferentes. >>> O que eu posso fazer é checar o evento e se for do mesmo, os dados off >>> substituem os dados online. >>> Se for diferente eu crio um novo registro e todos os seus >>> relacionamentos... >>> >>> Essa foi uma solução que imagenei... mais não tenho idéia do impacto >>> disso. >>> Também tem o caso de tabelas como Pais, que não guarda o evento e é >>> comum ao sistema. Qdo eu sincronizar se houve registro no on e no off eu >>> vou ter q ao invés de update dar um insert e verificar todas as relações e >>> atualizar elas. >>> >>> Posso estar viajando e complicando a solução, por isso quero outras >>> opiniões antes q eu pire aqui... rsrs >>> >>> Valeu >>> >>> >>> >>> Em 6 de junho de 2012 09:18, felipe bastos <[email protected]>escreveu: >>> >>> So lembrando .. >>>> >>>> Se vai ter uma versao administrativa local (offline) nao vais precisar >>>> da admin online. >>>> >>>> A admin local (offline) com acesso a internet pode gerenciar tudo. >>>> Basta fazer com que tudo que aconteca offline seja replicado online. >>>> >>>> A versao offline (local ou in loco) vai ter acesso a Internet? >>>> Em 06/06/2012 08:19, "Newton Wagner" <[email protected]> escreveu: >>>> >>>> Não vi dificuldade, como você mesmo disse. >>>>> >>>>> O sistema online nunca vai sair do ar. Isso já resolve a sua >>>>> preocupação de que outras pessoas poderão se inscrever em outros >>>>> eventos. O seu sistema online, vai ficar online o tempo todo, e >>>>> gerenciando os vários eventos que o sistema permitir configurar. >>>>> >>>>> Na parte administrativa desse seu sistema online, você vai ter uma >>>>> funcionalidade de extrair os dados de um único evento para que possam >>>>> ser carregados na versão offline. >>>>> >>>>> Cada servidor offline que você gerar (ou seja, para cada evento >>>>> diferente), você terá só os dados daquele evento especificamente, e >>>>> poderá fazer a gestão inloco como Checkin dos inscritos, e etc. >>>>> >>>>> >>>>> Caso você precise retornar esses dados para o sistema online, o >>>>> processo será o mesmo. Ao final do evento, na aplicação offline você >>>>> cria uma funcionalidade pra extrair os dados e atualizar a aplicação >>>>> online, pra gerar por exemplo certificados de comparecimento nos >>>>> eventos. >>>>> >>>>> >>>>> 2012/6/5 felipe bastos <[email protected]>: >>>>> > Rpz .. vc tem de ver todos os detalhes da arquitetura com esse seu >>>>> cliente. >>>>> > >>>>> > 1. Os usuarios se inscreverao no server online. >>>>> > 2. O funcionario fará incricoes no server offline? >>>>> > 2.1. Subir atualizados do server offline para o online (qtde >>>>> ingressos). >>>>> > 3. Os usuarios ficarao proibidos de se inscrever online a partir da >>>>> X data. >>>>> > 4. O server offline fará requisicoes diarias ao server online para >>>>> atualizar >>>>> > o banco de dados. >>>>> > 5. Por ai vai. >>>>> > >>>>> > É provavel que online e offline tenham logicas diferentes .. ou >>>>> melhor .. >>>>> > online fica com o front-end (acesso dos usuarios) e offline fica com >>>>> o >>>>> > back-end (acesso admin). >>>>> > >>>>> > Se a replicacao com ip fixo ficar complicada, um server rest no >>>>> server >>>>> > online pode ajudar na replicacao dos dados. >>>>> > >>>>> > Espero ter ajudado. >>>>> > >>>>> > Em 05/06/2012 22:04, "Guilherme Maule" <[email protected]> >>>>> escreveu: >>>>> > >>>>> >> Fera, nao entendi a dificuldade na operação? >>>>> >> >>>>> >> Acredito que exite varias maneiras de chegar ao mesmo resultado. >>>>> Por que >>>>> >> não baixa os dados no dia que vai parar as inscrições para o banco >>>>> local e >>>>> >> trabalha com ele offline e apos o evento, cria uma action que vai >>>>> subir e >>>>> >> atualizar as informações? >>>>> >> >>>>> >> Em poucas linahs voce escreve isto... Mada seu cliente executar a >>>>> função X >>>>> >> que vai fazer o download do banco-online para o banco-offline. Apos >>>>> o evento >>>>> >> manda seu cliente conectar o serve a intenet e executar a função Y. >>>>> Que vai >>>>> >> fazer o upload dos dados do banco-offline para o banco-online... >>>>> >> >>>>> >> #) >>>>> >> >>>>> >> Uma sugestão apenas... >>>>> >> >>>>> >> Em 5 de junho de 2012 20:43, Paulo Duarte < >>>>> [email protected]> >>>>> >> escreveu: >>>>> >>> >>>>> >>> Boa noite pessoal, >>>>> >>> estou desenvolvendo um projeto (php/kohana + mysql) que tem por >>>>> objetivo >>>>> >>> basicamente gerenciar dados de eventos (inscrições, cracha, etc). >>>>> >>> >>>>> >>> O sistema vai funcionar online (na maior parte do tempo). >>>>> >>> O problema que estou enfrentando é que no dia do evento, o sistema >>>>> deve >>>>> >>> estar funcionando off line (somente os dados do evento que está >>>>> >>> acontecendo). >>>>> >>> O porque disso: O cliente termina as inscrições online alguns dias >>>>> antes >>>>> >>> do evento para ter tempo de organizar os dados. >>>>> >>> No dia do evento ele não utiliza internet, são máquinas numa rede >>>>> local >>>>> >>> que devem acessar o sistema para verificar os dados do evento em >>>>> questão. >>>>> >>> >>>>> >>> Até aí tudo certo, teoricamente bastaria o cliente ter um server >>>>> >>> configurado no local do evento e importar o banco do ar no local. >>>>> >>> O problema é que o sistema gerencia mais de um evento. O >>>>> escritório do >>>>> >>> meu cliente estará atendendo e recebendo inscrições de outros >>>>> eventos >>>>> >>> (online) e o cliente precisa estar inloco com o sistema offline >>>>> funcionando >>>>> >>> com os dados daquele evento. >>>>> >>> >>>>> >>> Nunca um evento será gerenciado off e on ao mesmo tempo, assim eu >>>>> posso >>>>> >>> parar todas as informações referentes aquele evento, usar offline >>>>> e depois >>>>> >>> subir elas subscrevendo o que havia de dados do evento em >>>>> específico. >>>>> >>> >>>>> >>> Bom, possíveis soluções: >>>>> >>> 1) Ter um banco de dados para cada evento. Desta forma bastaria >>>>> exporta o >>>>> >>> banco em questão e importar na estrutura offline, e depois fazer o >>>>> processo >>>>> >>> contrário para deixar o sistema online atualizado. >>>>> >>> >>>>> >>> 2) Sincronizar os bancos (nunca fiz nada parecido, não conheço os >>>>> >>> obstáculos). >>>>> >>> >>>>> >>> >>>>> >>> Alguém já passou por situação semelhante e teria alguma direção >>>>> para me >>>>> >>> dar? >>>>> >>> >>>>> >>> Obrigado!! >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> -- >>>>> >>> Atenciosamente, >>>>> >>> >>>>> >>> >>>>> >>> Paulo Duarte >>>>> >>> Inteligência Web - Comunicação e Sistemas >>>>> >>> >>>>> >>> Fone: (48) 3028.5141 / 8426.3629 >>>>> >>> E-mail: [email protected] >>>>> >>> Skype: paulo.iw >>>>> >>> >>>>> >>> >>>>> >>> >>>>> ------------------------------------------------------------------------------------------- >>>>> >>> Aviso de confidencialidade: >>>>> >>> Esta mensagem da Empresa IW - Inteligência Web Comunicação e >>>>> Sistemas, >>>>> >>> empresa privada, é enviada exclusivamente a seu destinatário e >>>>> pode conter >>>>> >>> informações confidenciais, protegidas por sigilo profissional. Sua >>>>> >>> utilização desautorizada é ilegal e sujeita o infrator às penas da >>>>> lei. Se >>>>> >>> você a recebeu indevidamente, queira, por gentileza, reenviá-la ao >>>>> emitente, >>>>> >>> esclarecendo o equívoco. >>>>> >>> >>>>> >>> -- >>>>> >>> Você está recebendo esta mensagem porque se inscreveu no grupo >>>>> "Kohana >>>>> >>> Php" dos Grupos do Google. >>>>> >>> Para postar neste grupo, envie um e-mail para >>>>> >>> [email protected]. >>>>> >>> Para cancelar a inscrição nesse grupo, envie um e-mail para >>>>> >>> [email protected]. >>>>> >>> Para obter mais opções, visite esse grupo em >>>>> >>> http://groups.google.com/group/kohana-php?hl=pt-BR. >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> -- >>>>> >> >>>>> >> Att, >>>>> >> Guilherme Maule dos Reis >>>>> >> Web Designer >>>>> >> >>>>> >> 43 - 9129 1400 >>>>> >> >>>>> >> >>>>> >> -- >>>>> >> Você está recebendo esta mensagem porque se inscreveu no grupo >>>>> "Kohana >>>>> >> Php" dos Grupos do Google. >>>>> >> Para postar neste grupo, envie um e-mail para >>>>> [email protected]. >>>>> >> Para cancelar a inscrição nesse grupo, envie um e-mail para >>>>> >> [email protected]. >>>>> >> Para obter mais opções, visite esse grupo em >>>>> >> http://groups.google.com/group/kohana-php?hl=pt-BR. >>>>> > >>>>> > -- >>>>> > Você está recebendo esta mensagem porque se inscreveu no grupo >>>>> "Kohana Php" >>>>> > dos Grupos do Google. >>>>> > Para postar neste grupo, envie um e-mail para >>>>> [email protected]. >>>>> > Para cancelar a inscrição nesse grupo, envie um e-mail para >>>>> > [email protected]. >>>>> > Para obter mais opções, visite esse grupo em >>>>> > http://groups.google.com/group/kohana-php?hl=pt-BR. >>>>> >>>>> >>>>> >>>>> -- >>>>> Newton Wagner >>>>> >>>>> msn/gtalk: [email protected] >>>>> twitter: http://twitter.com/newtonwagner >>>>> site: http://www.newtonwagner.net/ >>>>> >>>>> -- >>>>> Você está recebendo esta mensagem porque se inscreveu no grupo "Kohana >>>>> Php" dos Grupos do Google. >>>>> Para postar neste grupo, envie um e-mail para >>>>> [email protected]. >>>>> Para cancelar a inscrição nesse grupo, envie um e-mail para >>>>> [email protected]. >>>>> Para obter mais opções, visite esse grupo em >>>>> http://groups.google.com/group/kohana-php?hl=pt-BR. >>>>> >>>>> -- >>>> Você está recebendo esta mensagem porque se inscreveu no grupo "Kohana >>>> Php" dos Grupos do Google. >>>> Para postar neste grupo, envie um e-mail para >>>> [email protected]. >>>> Para cancelar a inscrição nesse grupo, envie um e-mail para >>>> [email protected]. >>>> Para obter mais opções, visite esse grupo em >>>> http://groups.google.com/group/kohana-php?hl=pt-BR. >>>> >>> >>> >>> >>> -- >>> Atenciosamente, >>> >>> >>> *Paulo Duarte* >>> Inteligência Web - Comunicação e Sistemas >>> >>> Fone: (48) 3028.5141 / 8426.3629 >>> E-mail: [email protected] >>> Skype: paulo.iw >>> >>> >>> ------------------------------------------------------------------------------------------- >>> Aviso de confidencialidade: >>> Esta mensagem da Empresa IW - Inteligência Web Comunicação e Sistemas, >>> empresa privada, é enviada exclusivamente a seu destinatário e pode conter >>> informações confidenciais, protegidas por sigilo profissional. Sua >>> utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se >>> você a recebeu indevidamente, queira, por gentileza, reenviá-la ao >>> emitente, esclarecendo o equívoco. >>> >>> -- >>> Você está recebendo esta mensagem porque se inscreveu no grupo "Kohana >>> Php" dos Grupos do Google. >>> Para postar neste grupo, envie um e-mail para >>> [email protected]. >>> Para cancelar a inscrição nesse grupo, envie um e-mail para >>> [email protected]. >>> Para obter mais opções, visite esse grupo em >>> http://groups.google.com/group/kohana-php?hl=pt-BR. >>> >> >> -- >> Você está recebendo esta mensagem porque se inscreveu no grupo "Kohana >> Php" dos Grupos do Google. >> Para postar neste grupo, envie um e-mail para [email protected] >> . >> Para cancelar a inscrição nesse grupo, envie um e-mail para >> [email protected]. >> Para obter mais opções, visite esse grupo em >> http://groups.google.com/group/kohana-php?hl=pt-BR. >> > -- > Você está recebendo esta mensagem porque se inscreveu no grupo "Kohana > Php" dos Grupos do Google. > Para postar neste grupo, envie um e-mail para [email protected]. > Para cancelar a inscrição nesse grupo, envie um e-mail para > [email protected]. > Para obter mais opções, visite esse grupo em > http://groups.google.com/group/kohana-php?hl=pt-BR. > -- Você está recebendo esta mensagem porque se inscreveu no grupo "Kohana Php" dos Grupos do Google. Para postar neste grupo, envie um e-mail para [email protected]. Para cancelar a inscrição nesse grupo, envie um e-mail para [email protected]. Para obter mais opções, visite esse grupo em http://groups.google.com/group/kohana-php?hl=pt-BR.
