Olá pessoal!
Como posso fazer um sistema multiusuário?
Não sei muito de programação, mas tento, tanto que saiu um sistema, mas eu gostaria que este sistema fosse para vários usuários com seus dados.
Alguém pode me ajudar?
existem 1001 maneiras de fazer neston…
a minha é a seguinte:
usando subdominio.
quando o cliente acessa fulano.sitedoseusistema.com.br
na app de login vc concatena o http://fulano.sitedoseusistema.com.br
separa e pega apenas o fulano pra usar como conexão no prod
daí cria uma variavel de sessao na app de login em eventos onValidateSuccess assim:
$_SESSION[‘scriptcase’][‘variavel_que_vc_quiser’] = “conn_fulano_mysql”;
depois em todas as apps, fora a de login, vc coloca o comando pra trocar de conexão dinamicamente
em onApplicationInit
na primeira linha assim:
sc_change_connection(‘conn_default_mysql’, $_SESSION[‘scriptcase’][‘variavel_que_vc_quiser’]);
detalhe: a conexão conn_fulano_mysql tem q estar criada no prod
tipo quando vc coloca em produção vc define uma conexão pro db
supondo q vc usa MySQL e q a conn padrão tua é conn_default_mysql
pro fulano acessar um db dele, obviamente vai precisar criar um db definido fulano no banco de dados
e no prod além da conn_default_mysql tem q haver a conexão conn_fulano_mysql ligando ao db fulano
conseguiu entender?
pra mim funciona q é uma beleza.
tenho um prod apenas
varias conn
varios clientes
e apenas um codigo
valeu.
E a manutenção de cada banco quando vem as alterações, usa algum software específico?
a resposta tá na própria pergunta.
só q essa seria pra outro tópico.
mas como é pertinente…
eu uso phpmyadmin quando é pouca a mudança.
não tenho muita frescura.
no geral crio um update.php no dreamweaver com os comandos sql.
faço uma chamada do update.php na aplicação de login do projeto.
quando o cliente loga a primeira vez depois da mudança é acionado o update.php
se for necessário ele atualiza conforme a versão
pq mantenho no db uma tabela da versão pra comparar.
em 10 segundos o db é atualizado.
se tiver um cloud podes usar ssh pra dar um comando só pra todos bancos.
entendeu?
Há uma diferença muito grande de sistema Multiusuário para sistema Multiempresa.
concordo.
multiempresa é quando vc gerencia mais de uma empresa no mesmo banco de dados.
meu sistema é assim, tenho clientes diferentes e cada um usa o seu próprio db.
mas cada cliente pode usar mais de uma empresa no seu próprio db.
controlado por Emitente.
na hora de gerar dados é selecionado qual Emitente usar pra nota sair conforme desejado.
pq tenho cliente de madeireira que tbm tem transportadora pra economizar.
assim saí a nota e o ct do mesmo sistema mas com emitentes diferentes.
isso envolve toda a estrutura do sistema que precisa ser pensado quando vais criar o sistema.
mas esse tbm é assunto pra outro tópico.
a pergunta da amiga acima foi bem especifica… não foi muito clara, mas se eu entendi bem,
ela quer usar o mesmo código pra clientes diferentes.
cada cliente usando seu próprio db.
Isso Clarck.
Tenho um sostema de Laudos Médicos e gostaria de poder ter varias empresas e Clientes utilizando mas com uma aplicação só.
Tem tempo q não faço algo no scriptcase e proticamente qua nao tenho muita experiência, mas estudo e me esgorco.
Por isso gostaria de entender e saber como faz para desenvolver.
Minha versao e a 8.1
Agradeço muito aos amigos acima q estão me orientamdo e quanto mais informacso melhor.
Hoje eu utilizo sistema Multiempresas.
O Sc infelizmente não é 100% Multiusuário.
Tenho um banco de dados para cada grupo de empresas.
o acesso ao grupo de empresas se dá pela url: https://dom.com/sistema/login/login.php?grupo=XXXX
Tenho uma conexão para cada grupo apontando para o banco de dados específico.
No evento onscriptinit da app login mudo a conexão padrão para a conexão XXXX que vem na global [grupo]
O Login abre as empresas do grupo para selecionar antes de entrar no menu.
Manutenção nos bancos:
Todo alter table, create, etc, salvo numa tabela de alteraçãoes de sql nos bancos de dados. O primeiro login do dia verifica quais querys precisam ser rodadas no banco de dados e as executa, enquanto isso ninguém consegue se logar, após a execução o sistema libera o uso normal.
é como o Haroldo disse… tem diferença e é enorme.
por ex.:
meu cliente de madeireira…
ele tem cadastrado no sistema 2 CNPJ
1 da madeireira
1 da transportadora
ambos são dele mesmo.
são 2 certificados eletrônicos, um pra cada empresa.
mas aqui temos um detalhe q faz toda a diferença: campo emitente em todas as tabelas dos db.
isso pra identificar de qual Emitente está sendo manipulada cada informação.
Mas o meu sistema é o único q eu vi até hj q não precisa deslogar pra mudar de CNPJ
é feito tudo dinamicamente.
tipo quando vais gerar um orçamento ou pedido ou contas a receber ou caixa ou contas a pagar…
tem um select no inicio do formulario pra escolher qual CNPJ Emiente está sendo referida a informação.
mesma tabela com informações de Emitente diferente, na hora de gerar relatórios e tudo mais basta filtrar.
é facil falar quando já está pronto, mas dá muito trabalho…
por isso repito, isso deve ser bem pensado no inicio do projeto…
com o bonde andando vais penar.
valeu?
Estou em um projeto, comecei com com multiusuário, mas percebi que seria interessante multiempresa, tive que reestruturar toda a minha modelagem de banco, está sendo penoso, e optei por ter um único banco para todos, fiz esta escolha mediante o objetivo do meu projeto…
Enfim dá muito trabalho, e abortei a questão de múltiplos bancos devido ao trabalho e manutenção, para mim seria inviável…
Valew pelas experiências trocadas, quem sabe futuramente eu repenso nesta mesclagem do Haroldo e Clarck…
um banco pra todos daí vc quebra o servidor. além de criar um arquivo muito grande acaba q o processo fica lento.
mesclar? daí não.
Mas o meu sistema é o único q eu vi até hj q não precisa deslogar pra mudar de CNPJ
é feito tudo dinamicamente.
“O meu faz isso a uns 3 anos…”
vc pegou uma frase sem entender o contexto.
não to falando em filiais.
o teu é só de construção civil.
até onde me lembro do teu sistema, o login é com CNPJ.
quando loga no teu vc consegue inserir dados de outro CNPJ sem logout pra entrar nesse outro CNPJ?
ex.:
tenho 3 empresa (mercado, material de construção e agropecuária) e faço login com Clarck
pra mexer nas 3 empresas não preciso fazer logout pra escolher uma delas.
“acho q o teu não faz não”
rsrsrsrs
Igual:
copiado do Haroldo: Hoje eu utilizo sistema Multiempresas.
Me permitam discordar do conceito de ‘Multiusuário’ e ‘Multiempresa’ que vocês adotaram…
O fato de ser multiusuário ou multiempresa não entendo que determine que seja um único DB ou múltiplos DBs… Pode-se ter uma aplicação multiempresa em um único DB, basta que para isso você tenha várias empresas sendo controladas por uma única empresa (holding). Pode-se ter múltiplos domínios para um único DB, e por aí vai.
A forma como o Haroldo definiu, criando uma variável global para a conexão, no momento do login, racionaliza bastante a aplicação…
Eu já não faço assim… crio um sistema um pouco mais complexo onde o que importa é o proprietário do registro. Cada registro do meu DB possui um proprietário, que pode ser uma empresa, um usuário, um grupo de usuários ou um grupo de empresas…
Ambos os métodos possuem suas vantagens e desvantagens (alguém já disse que não existe almoço grátis) e entendo que o gargalo aqui é o DBA e não o SC. Pouco adianta vc optar por um ou múltiplos DBs se não souber montar uma boa query… o DB vai cair ou ficar muito lento. Tentem desnormalizar um ou múltiplos DBs em um único DW, sem ter o devido conhecimento que vocês vão ver o que vai acontecer.
Enfim, a discussão é muito pertinente, todas opiniões são bastante interessantes mas, na minha opinião, o que realmente importa é a simplicidade do produto final e nesse quesito um único DB é sem sombra de dúvida mais eficiente. Imagine que vc precise fazer uma alteração em uma tabela… se tiver múltiplos DBs terá que alterar todas elas…
Fraterno abraço.
[font=arial][size=small]Eu venho trabalhando num projeto de aplicativos de conta única, como o google. Através de uma unica conta se tem acesso aos aplicativos instanciados para o “dono”, gerente da instância. Isso possibilita pulverizar o banco em diversos hosts compartilhados, o que reduz custos tornando mais escalável. Os aplicativos são compartilhados entre si mas independentes por instâncias. Utilizando um conceito celular ao invés de modular se consegue maior flexibilidade.[/size][/font]
Concordo em algumas coisas…
Os termos Multiusuario e Multiempresa tbm são confusos pra mim, só usei pra tentar falar a língua da moça q levantou a questão.
Eu trabalho com empresas grandes, que tem varias empresas dentro delas.
No início era difícil conciliar tanta informação.
Com o Scriptcase isso mudou da agua pro vinho.
Um código pra todas, sem sofrer tanto tempo criando chaves e direcionamentos.
mas visualize o cenário de um cliente meu, nomeado como X:
1 contrato… onde esse cliente X especifica q quer um banco de dados exclusivo pra ele.
o cliente X tem 8 empresas. Importadora, distribuidora, transportadora, comercio etc…
nesse caso eu tive sair da tua ideia de um único db (único db seria mais confortável).
então um db pro cliente X e outro db pros outros 25 clientes.
esse cliente num db separado dos outros 25 me daria trabalho pra continuar
da forma tradicional.
desse contrato em diante passei a usar um db pra cada contrato (cliente).
logo ficou 26 db’s, ao invés do único db pra todos, q eu tinha.
sim tive trabalho no inicio, por que sempre há mudanças no db, praticamente todos os dias.
isso resolvi, como dito nas mensagens acima, no login q se ajusta o db conforme a necessidade e versão.
sobre a ideia do Haroldo de variável global na url: é uma ideia boa.
pra ele funciona e é suficiente, tá bom. Não desmereço o crédito dele.
mas, com subdomínio vc amplifica a ideia dele da seguinte forma:
além de usar o subdomínio como variável global, eu uso tbm pra emails internos, nfe, xml, ftp, etc…
toda uma estrutura formada e montada pra agregar valor, diminuir custo, agilizar manutenção…
eu deixo o servidor trabalhando por mim… assim ganho muuuuuito tempo.
eu nunca tive problema com macros de emails do scriptcase por ex.
eu como cliente de mim mesmo ficaria frustrado de ter q ficar configurando emails externos
ligação com ftp externa…
aquele saco q é o serviço de téc. informática.
Contratar outra empresa pra fazer esse serviço? nem a pau… pra cagar no meu trabalho?
Enfim, foi a melhor estratégia q encontrei pra focar no q eu realmente gosto de fazer.
concluindo:
- 1 subdomínio pra cada contrato (cliente).
- 1 db pra cada contrato
- varias empresas (não necessariamente holding) no mesmo db, do mesmo contrato.
- 1 código php pra todos os db’s
- 1 prod pra todos com a conexão de cada db.
idem.
Multiusuário ou multiempresa não tem a ver com o banco mesmo.
Multiempresa pode ser em um banco só ou em bancos diferentes.
Multiusuário quer dizer aplicações concorrentes simultaneamente abertas no mesmo registro.
Exemplo: App Cliente aberta para o cliente XYZ em dois terminais diferentes ao mesmo tempo, um terminal o usuário altera o endereço em outro o usuário altera o telefone. No caso do SC o que salvar por último vai matar a alteração do primeiro. Num caso de reserva de passagens é muito comum.
Uma app multiusuário salva apenas os campos que foram alterados e antes de salvar trava o registro, faz um reread com lock no registro e update apenas nas colunas alteradas, depois destrava e comita.
sim.
mas como vamos padronizar então essas ideias?
vc q é bom de nome, quando sugeriu “Biblioteca Externa e Interna”.
código muti-db?
Nem todo sistema tem a necessidade de ser multiempresa, mas a meu ver todo o sistema deveria ser 100% multiusuário.
É difícil eu dizer, ou melhor, eu sugerir uma opção mais viável, pois eu mesmo as vezes me pego em situações que desejaria ter usado outro conceito.
Bons tempos do Unify, bancos, tabelas, colunas ficavam tudo dentro de um arquivo único.
Separar os bancos por empresa acho que é mais negociável, pois meus contratos garante que o cliente obtenha uma cópia do banco com seus dados sempre que solicitar.
Mas juntar as empresas de uma mesma corporação em um único banco também faz sentido, pois podemos consolidar informações, realizar transferências entre empresas mais facilmente.
Eu acredito que cada um deve analisar todos os prós e contras antes de desenvolver, pois depois de estruturado e em produção a mudança é muito radical.