Dúvida sobre banco de dados único ou separados

[Prof. Baco]

Olá meus amigos tudo bem?

Estou com a seguinte dúvida. Desenvolvi um sistema para minha irmã e 4 empresas viram o sistema e querem e estou em negociação com mais 3 outras empresas.

Ao utilizarem o sistema tenho uma pasta "public/sistema" e cada cliente tem um subdomínio que é redirecionado para esta pasta pelo apache, mas a minha dúvida é o seguinte.

O que fazer com o banco de dados, deixo os bancos de dados separados, ou deixo eles unificados.

VANTAGENS DE SEPARADOS

1) Se der um problema de um cliente eu posso parar somente ele e continuar os demais trabalhando

DESVANTAGEM

1) Cada manutenção de banco, devo fazer para todos (a pesar que isto posso fazer uma rotina para atualizar para todos ao mesmo tempo)

Bom e aí, o que vocês sugerem?

Atenciosamente,

Prof. (Baco) Edmar Carvalhaes
Consultor - Professor - Programador Client/Server

edmarca...@gmail.com
SomarTech Tecnologia e Serviços ME
Consultec Tecnologia e Serviços ME

+55 (62) 8140-0462

[Ole Peter Smith]

Eu deixaria separados... assim posso separar em maquinas separados se for preciso, sem ter que manter copias de codigos separados.

Uso um parm cgi, ex Unit=2, que daria no banco com nome ex 2__mysystem. Sem muitos  probs, pois so preciso do nome do banco na hora de iniciar a conexao.

Ole, via celular

--
Você recebeu esta mensagem porque está inscrito na Lista "GOPHP" em Grupos do Google.
Para Postar: go...@googlegroups.com
Para Sair do Grupo: gophp-un...@googlegroups.com
Link: http://groups.google.com/group/gophp?hl=pt-BR
---
Você recebeu essa mensagem porque está inscrito no grupo "GOPHP" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para gophp+un...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

[Ole Peter Smith]

uma alternativa, claro, seria usar tabelas separadas no mesmo banco, nomeando elas: 2__Users, 2__Places, etc. 

0le

--

                                                    /////
                                                 ( O O )
=================oOO==(_)==OOo=================

            Every day and every hour, I'm Learning more

          The more I Learn, the less I Know about before

         The Less I know, the more I want to Look around

             Diggin' deeper into Higher Ground...  UB40

                                   .oooO Oooo.
==================(     )=(     )=====================
                                     \  (     )  /
                                      \_)   (_/
===============================================
                        Ole Peter Smith, IME, UFG
            http://olepeter.mat.ufg.br  - ole at ufg.br
===============================================
                   Life sure is a Mystery to be Lived
                      Not a Problem to be Solved
===============================================

[Prof. Baco]

Por exmplo, aquelas empresas que tem ERP web onde a pessoa faz o cadastro, será que o banco e unificado ou separado? Lembrado que a pasta do sistema e única mas obanco que e meu problema.

[Ole Peter Smith]

divide and conquer?

0le

[Marcel Ferrante]

O wordpress faz desse jeito, wp_posts_3, sendo o numero no final o ID do blog. Entretanto a tabela de usuarios é comum (por questao de autenticacao, etc).

Seria interessante da uma olhada.Ex:

Abs

Marcel

Marcel Ferrante Silva

Professor Adjunto no Curso de Gestão da Informação - FIC / UFG

+55 62 8108-1277

skype:marcelferrante / gtalk:mar...@gmail.com

lattes.cnpq.br/6034149800479841

[Leonardo Oliveira]

Minha opinião: único com certeza! Os benefícios são muito maiores do que os malefícios. Coloque uma tabela pai "empresa" e chaveie os registros com os ids das empresas. Seu negócio pode crescer muito e "replicar tarefa" é um grande problema para uma equipe que precisa ser pragmática. Você está pensando em cinco, seis empresas, mas pense em 50, 100! Como seria dar manutenção nisso?

[Leonardo Oliveira]

Ah! Uma coisa importante que esqueci de falar. Tente hospedar o banco de dados em um ótimo datacenter com bkp no mínimo semanal. Bom não, ótimo!

[Prof. Baco]

Oi Leonardo, hoje o sistema já esta operando multi-empresas, onde um cliente pode, só ele, ter várias empresas na mesma instância - lembrando que ele tem que selecionar a empresa que deseja trabalhar antes de iniciar, e gravo no banco o ID da empresa normalmente - mas o meu medo é se der um problema em um cliente, vai dar problemas em todos.

Sobre outra dúvida em ser único:

1) Se o banco cresces demais, uma vez que teremos vários clientes no mesmo banco, fazendo com que ele incha muito rápido, o que fazer?

2) O cliente que não deseja mais ter o sistema, como fazer para remover os registros de sua base de dados (hoje eu tiro um backup de sua base e entrego os dados para o cliente e espero 30 dias e se não voltar eu já excluo sua base)

Atenciosamente,

Prof. (Baco) Edmar Carvalhaes
Consultor - Professor - Programador Client/Server

edmarca...@gmail.com
SomarTech Tecnologia e Serviços ME
Consultec Tecnologia e Serviços ME

+55 (62) 8140-0462

--

[Marcel Ferrante]

Baco,

o ruim de voce criar uma tabela empresa e relaciona-la em todas outras as tabelas (ex. pedidos), é que se vc cometer algum erro, pode ocorrer de vc mostrar pedidos errados para um cliente. Tambem fica mais dificil de voce escalar e um cliente com 10 milhoes de pedidos pode atrapalhar um cliente com 10 mil pedidos pq tudo vai estar na mesma tabela. 

Deixando um unico banco com tabela independentes, evita esse tipo de situacao e permite no futuro vc distribuir essas tabelas em varios servidores. Bem o wordpress.com tem milhoes de blogs, e eles optaram por essa solucao, entao deve ter algum motivo.

Abs

Marcel

[Leonardo Oliveira]

Aqui já não tínhamos muito problemas com banco de dados quando era hospedado em servidor próprio, na verdade quase zero de problema relativo aos dados. Depois que colocamos o banco em um datacenter importante, não tivemos mais nenhum tipo de problema. Nunca tivemos que voltar nenhum bkp por exemplo. A meu ver, quando o banco está na nuvem não tem problema, os problemas de banco acontecem muito em sistemas desktop em que o cliente tem o banco em um servidor na empresa. Aí sim temos alguns problemas (temos sistema web e desktop). Mas na nuvem, em um datacenter, o máximo que acontece é perder a conexão por algum motivo, como um dia em que um cabo de fibra ótica em são paulo foi rompido, mas é só problema de conexão, o sistema fica inoperante por um tempo, mas depois o serviço é retomado, os dados estão intactos, e isso é o que importa. Portanto, com o datacenter você responde à questão de inchaço e de segurança. Se inchar demais eles simplesmente trocam o hd por um maior (coisa rara de acontecer), se estiver lento peça mais memória, processamento, e por aí vai. Quanto à segunda questão, não sei como acontece aqui com empresas que rompem o contrato, mas nunca me foi solicitado pra pegar nada na base do cliente por ocasião de rompimento, na verdade, as empresas entram e ficam por muitos anos, não tem porque montar um sistema pensando em rompimento de contrato, mas mesmo assim, se algum cliente quiser seus dados, dá trablalho, mas dá pra fazer um select na base dele e entregar via planilha, sei lá. O fato é que o modelo de dados não é do cliente, mas nosso. não damos um MER pro cliente, ele paga uma mensalidade pra usufruir do sistema, é isso.

Resumindo tudo: bando de dados único, se eu tivesse que alterar o banco de mais de cem empresas eu ficaria por conta disso o dia inteiro.

[Prof. Baco]

Marcel uma dúvida sobre banco único mas com tabelas diferentes. Ao fazer manutenção no banco, não fica mais complicado eu ter que setar todas as tabelas seguida pelo mesmo modelo do WP? Exemplo, a tabela de PEDIDOS terei PEDIDOS_1, PEDIDOS_4 e PEDIDOS_20, sendo que o número seria o ID do cliente, por suposição. Se fizer uma alteração em um campo nesta tabela terei que fazer isto para cada tabela dela.

1) Se for banco único com tabela única a alteração é somente uma

2) Se for banco único com tabelas distintas, tenho que achar uma rotina para fazer estas alterações - mas tenho segurança das tabelas de cada cliente

3) Se for banco separado, tenho que achar uma rotina para estas alterações - mas tenho bancos distintos sem precisar parar ninguém.

Ambos tem vantagem e desvantagem, mas ainda vem sobre a usabilidade e menor custo de manutenção.

Atenciosamente,

Prof. (Baco) Edmar Carvalhaes
Consultor - Professor - Programador Client/Server

edmarca...@gmail.com
SomarTech Tecnologia e Serviços ME
Consultec Tecnologia e Serviços ME

+55 (62) 8140-0462

[Ole Peter Smith]

concordo plenamente que divisao eh imprescindivel. imagina so um log do sistema...

precisa-se, porem, usar a organizacao logica dos dados armanezenados, para aproveitar essa logica a uma nomeacao simples e logico das tabelas.

por ex, desenvolvo um sistema de admin escolar (notas, diarios eletronicos, etc). se nao subdivido por periodo, daqui a pouco a quantia de entradas sera bem grande (ja tem-se 8 anos de dados...). tendo tambem varias escolas, providenciando outro parametro divisor. Nomeia da seguinte forma:

$idescola__Classes,

$idescola__$idperiod__Marks

Ja que tenho esse nocao instalado, de forma simples, ainda podia para os diarios (que tem muito mais dados), extender para:

$idescola__$idperiod__$idclasse__Marks

Penso nesses parametros divisores como uma coluna da tabela, que esta sendo 'gravada' no titulo da tabela.

No mais, queria ter sistematica usado __ (dois _)neste nomeacao (vou alterar um destes dias), pois phpmyadmin faz uma associacao como um tipo de 'pasta' no menu esquerda, invisibilizando os matches com um 'abrivel' + - muito pratico!

0le

[caferrari]

Minhas experiências com divisão de databases não foram nada boas, no Tocantins minha equipe ( eu e mais um) cuidavamos de 49 sites, cada um com sua base de dados, um CMS central que gerenciava tudo, dependendo do usuário, se conectava na base de dados correspondente... era um parto fazer qualquer coisa, uma modificação no sistema demandava  backup e alteração das 49 bases, um bug que era descoberto era uma canseira de mudar.

Fizemos uma nova versão em 2008, com apenas uma base de dados unificada com arquitetura SOA em PHP, nossos problemas terminaram e o sistema está perfeito até hoje. sem grandes dores de cabeça, qualquer coisa podia ser resolvida com apenas um comando SQL na base.. backup e updates ficaram bem mais tranquilos.

[]'s

Carlos André Ferrari
http://ferrari.eti.br
http://github.com/caferrari
http://meadiciona.com/caferrari
OpenPGP keys: 113D04FC

[Leandro Araujo]

Boas Baco,

Banco de dados único você fica com uma bomba relógio nas mãos, a solução de "database in cloud" realmente sana a questão de espaço e desempenho mas não de segurança da informação ( quando digo segurança da informação é o acesso indevido aos dados de um determinado cliente tanto por técnicas de invasão e erros de programação).

O sistema é único os arquivos são únicos e versionados com git/svn tanto faz (prefiro git) e quando modifica sua estrutura única pode ocorrer de o programador realizar um JOIN ou WHERE sem validar o ID do cliente, sendo assim vai percorrer toda a tabela de 10milhões de registros e retornar pedidos de outras empresas fazendo a maior bagunça em sua estrutura de dados e isso meu amigo em ambiente de produção com BD único é um caos tremendo que vai se arrepender eternamente por não ter separado por schemas cada cliente e cada schema com seu USER, desta forma não deixa que o mesmo user de um determinado schema tenha acesso a outro schema, por exemplo quando façam selects de resultados de schemas diferentes.

Levanto um ponto a não ser esquecido, pois nas mensagens anteriores notei que falaram do assunto e backup de banco de dados em ambiente de produção com dados de clientes e ainda mais dados fiscais é (no meu ponto de vista) inaceitável não ser implementado uma regra mínima diária/semanal/mensal com dados históricos de no mínimo 1 ano.

Claro que nem vamos falar em auditoria em um banco de dados único para o sistema que tenha valores fiscais de 10.000 empresas, neste caso vai ter mais um monte de problemas pois suas tabelas estão sujeitas a modificações inesperadas e se não me engano uma fiscalização vai gerar algumas multas por tal inconsistência.

Separando schema por cliente você evita ter que interromper o acesso das 10mil empresas por conta de um erro na modelagem de uma nova implementação na tabela por solicitação de apenas 1 clientes onde o mesmo deseja personalizar um recurso para o sistema dele em particular, ou isso não é possível e aceitável na sua estrutura?

Mas claro que isso depende sempre do projeto e dos requisitos pois existem várias formas de solucionar um problema a questão é analisar da melhor forma possível e avaliar os riscos que se possa enfrentar, só que uma coisa é certa, misturar dados de empresas não é a mais indicada das soluções.

At.

Leandro

Em 23 de fevereiro de 2015 09:17, Leonardo Oliveira <leonardoc...@gmail.com> escreveu:

[caferrari]

Eu manteria tudo junto, muito mais performático, fácil de atualizar o sistema, fazer backups e etc. 

Caso o sistema cresça, fica fácil botar o banco em um servidor dedicado e escalar conforme necessário, seja horizontalmente ou verticalmente.

Porém este "aproach" demanda um cuidado extra (que deveria ser considerado de qualquer forma): segurança.

Sugiro também que você faça o sistema já considerando mecanismos mais eficientes de armazenamento de sessions, como o memcached ou redis, isso vai te trazer muita tranquilidade na hora de escalar os webservers horizontalmente.

[Leandro Araujo]

Bom dia,

Sem nenhuma dúvida que seria separado até mesmo por segurança da informação, e cada schema com user separado para cada cliente, estamos falando de dados de empresas que "supostamente" é informação sigilosa e de muita importância.

Em meus sistemas quando se trata de mais clientes com a mesma estrutura sempre separo por schemas (postgresql), se juntar tudo em um só banco vai ter muitos problemas até mesmo se um dia precisar exportar ou migrar apenas 1 cliente para uma outra estrutura, e também podemos pensar em performance, pois se tu conseguir um cliente que usa recursos do BD com maior frequência e consome muito mais espaço que os demais clientes é injusto para os demais clientes terem a perca de performance.

Em minha opinião eu nunca optaria em deixar tudo em um só banco de dados por NN fatores os quais citei alguns acima e a "vantagem" de atualização que o Sr. citou acima não é bem uma vantagem pois até mesmo encontrou uma alternativa para esta vantagem que poderia ter.

Mas como disse, esta é minha humilde opinião.

At.

Leandro Araújo

Em 23 de fevereiro de 2015 02:10, Ole Peter Smith <ole...@gmail.com> escreveu:

[Atila augusto]

Use sistema de prefix mesmo e um banco de dados Oracle pra segurar o tranco legal.

Atila Augusto
Desenvolvedor de software
Contato Freelance: 974532617
Via Windows Phone 8.1

---

De: Leonardo Oliveira
Enviada em: ‎23/‎02/‎2015 08:15
Para: go...@googlegroups.com
Assunto: [gophp] Re: Dúvida sobre banco de dados único ou separados

--

[weusder monteiro mascarenhas]

Concordo com todas as vantagens e desvantagens citadas para os cenários apresentados.

Mas ter as empresas em bancos separados, ao meu ver, traz mais flexibilidade.

Sempre tem a possibilidade de um cliente, "bater o pé" e querer que o banco fique no servidor dele.

Outra possibilidade seria uma customização para atender um cliente específico.

Enfim quando se trata de negócios e tecnologia, sempre temos particularidades, por isso minha opção por algo que traga 

mais flexibilidade.

Atenciosamente

Weusder Monteiro

[Rafael Fideles]

Meu palpite é fazer apenas um banco de dados com várias instâncias/schemas, acredito que seja simples de manter está pensando em qual SGBD?

--

[caferrari]

Sua frase de dividir e conquistar está absolutamente correta, porém eu considero dividir como "escalabilidade horizontal". O banco está crescendo muito rápido? particione ele em mais de uma maquina. O sistema está ficando carregado, espalhe o webserver em mais de uma maquina. Bem mais tranquilo de fazer =).

[caferrari]

Pense de outra forma, se vc tiver 50 clientes e aparecer um bug crítico, em quanto tempo você resolveria o problema nas 50 bases?

Sobre o crescimento do banco existem vários mecanismos para você trabalhar:

1) Partitions (já é bom pensar nisso desde o inicio)
2) Replicação (master-slave ou até master-master)
3) Mais hardware (escalabilidade vertical)
4) Mais maquinas (escalabilidade horizontal)

Em 23 de fevereiro de 2015 08:27, Prof. Baco <edmarca...@gmail.com> escreveu:

[Prof. Baco]

Bom, acho que vou fazer em base única por causa dos versionamentos e atualizações. Estive pensando sobre o cliente que deseja particularidades, estes clientes, vou ter que separar pois existe regras de negócios específicas pra ele, e por causa destas regras ele terá um custo adicional que os demais não terão.

Vou fazer os teste com banco único, com separação somente, caso haja customizações ele paga a conta de ter um registro só para ele. O que acha?

Atenciosamente,

Prof. (Baco) Edmar Carvalhaes
Consultor - Professor - Programador Client/Server

edmarca...@gmail.com
SomarTech Tecnologia e Serviços ME
Consultec Tecnologia e Serviços ME

+55 (62) 8140-0462

[Leandro Araujo]

Baco em relação a regra de negócio é onde entra o MVC, crie uma estrutura capaz de suportar personalizações de clientes sem interferir com os módulos base do sistema, use herança de métodos e faça desta forma um sistema escalável pois se desmembrar e tiver 50 clientes com personalização consequentemente vai ter 50 estrutura separadas e seu cenário ainda piora mais pois nunca mais vai conseguir atualizar módulos básicos de forma unificada como é o objetivo e isso vai impedir de teu sistema ser escalável.

Bem eu acho que unificando a estrutura dos arquivos e separando os schemas seria a melhor solução, apenas na minha humilde opinião pois tanto para gerenciar como escalar este tipo de sistema é simples e as personalização dos clientes (tenha em mente que isso vai acontecer) é muito mais fácil de criar, imagine que precise de criar tabelas, templates diferente, regra de negócio exclusiva, isso tudo é possível acontecer no seu sistema? então se decidir por unificar acho que vai encontrar algumas dificuldades que não seria necessário enfrentar.

At.

Leandro Araujo

Em 23 de fevereiro de 2015 15:08, Leandro Araujo <pingu...@gmail.com> escreveu:

@caferrari

Pense de outra forma, se vc tiver 50 clientes e aparecer um bug crítico, em quanto tempo você resolveria o problema nas 50 bases?

No mesmo período de tempo que iria demorar para resolver para um único schema (entendam que quando falo schema me refiro ao PostgreSQL e no mysql se não me engano o conceito de schema é banco de dados.), temos ferramentas que faz com que executamos um MER direto em um determinado SGBD "Workbench e Power Archtect" são 2 excelentes ferramentas para modelagem de SGBD relacional e que te da essa possibilidade de executar seu projeto de modelo de dados bastando selecionar em qual conexão vai executar e se achar muito trabalhoso basta criar um script de atualização dos DDL e não me digam que isso é trabalhoso porque não é mesmo e com no máximo 10 linhas de código tem o script de atualização.

Em relação a mecanismos ou tecnologias/serviços para escalabilidade e desempenho não se esqueçam que tudo tem custos e no caso de cliente quanto menos custos melhor porque sua receita aumenta seu produto é melhor aceito e sem falar é claro na padronização.

Mas como já disse e também já foi mencionado não quer dizer que algumas das soluções acima não solucione o problema, o que tem que avaliar é a finalidade e os requisitos, pois imagino que tem sistemas já feitos para vários clientes com a mesma estrutura de dados sendo ela única e todos partilham da mesma tabela e ou banco de dados.

Não esqueçam que ao citar wordpress como exemplo tem que se lembrar que talvez o motivo pelo qual eles usam o sistema de banco de dados unificado deve ser pelo motivo de os desenvolvedores na grande maioria utilizarem servidores partilhados que os obrigam a usar na  maioria das vez apenas 1 estância de dados e por isso a solução foi a nomenclatura, pois imaginem se o wordpress obrigassem ao desenvolvedor a definir para cada blog gerenciado pelo CMS uma nova configuração de banco de dados? 

Apenas acho que unificar tudo em um schema é mais arriscado e mesmo tendo 1000 clientes quando tem a necessidade de fazer uma manutenção corretiva leva o mesmo tanto de tempo para atualizar se fosse para 1 schema, e se estamos falando em sistemas escaláveis e personalizáveis jamais seria possível de forma fácil e transparente fazer isso usando um único schema e ou banco de dados.

Antes de desenvolver um sistema tem que definir seus requisitos, arquitetura e ferramentas necessárias pois não vai dar certo desenvolver um sistema com vários schemas se não está preparado para a manutenibilidade do mesmo.

At.

Leandro Araujo 

[Leonardo Oliveira]

é isso aí. pragmatismo é tudo nesse meio.

[Leandro Araujo]

só para retificar minha última frase ficou parecendo incoerente, mas o certo seria:

...? então se decidir por não unificar a estrutura de arquivos acho que vai encontrar algumas dificuldades que não seria necessário enfrentar.

[Atila augusto]

Use e abuse da OO, para deixar seu sistema modular e escalável, desse modo vai ser como montar peças de lego.

Atila Augusto
Desenvolvedor de software
Contato Freelance: 974532617
Via Windows Phone 8.1

---

De: Leandro Araujo
Enviada em: ‎23/‎02/‎2015 15:20
Para: go...@googlegroups.com
Assunto: Re: [gophp] Re: Dúvida sobre banco de dados único ou separados

[Atila augusto]

Use e abuse da OO, para deixar seu sistema modular e escalável, desse modo vai ser como montar peças de lego.

Atila Augusto
Desenvolvedor de software
Contato Freelance: 974532617
Via Windows Phone 8.1

---

De: Leandro Araujo
Enviada em: ‎23/‎02/‎2015 15:20
Para: go...@googlegroups.com
Assunto: Re: [gophp] Re: Dúvida sobre banco de dados único ou separados

[Ole Peter Smith]

sistemas sao montagem de pecas de lego, OO eh que mais inspira abstracao...

no mais, concordo com a seperacao em entidades de fregueses, ou no banco, ou nas tabelas.

porem insisto numa consideracao temporal, pois o sistemas precisam tmbm 'gravar a historia'... o que eh foda! tanto na consideracao de tamanho de tabelas (quantia de entradas)/bancos (quantia de tabelas), como na consistencia temporal por exemplode documentos impressos....

exemplo. gerei a ficha do servico tal, para fregues tal 2 anos atras. agora quero gerar novamente... mas os dados o fregues persistem?

gero a ficha de aluno de dois anos atras, deve sair o 'novo' endereco?

e nao consideracao de eficiencia? considero q

0le

[Ole Peter Smith]

caras enviei sem terminar, desconsidero email anterior...

sistemas sao montagem de pecas de lego, OO eh que mais inspira abstracao...

no mais, concordo com a seperacao em entidades de fregueses, ou no banco, ou nas tabelas.

porem insisto numa consideracao temporal, pois o sistemas precisam tmbm 'gravar a historia'... o que eh foda! tanto na consideracao de tamanho de tabelas (quantia de entradas)/bancos (quantia de tabelas), como na consistencia temporal por exemplode documentos impressos....

exemplo. gerei a ficha do servico tal, para fregues tal 2 anos atras. agora quero gerar novamente... mas os dados o fregues persistem?

gero a ficha de aluno de dois anos atras, deve sair o 'novo' endereco?

e na consideracao de eficiencia? considero que um sistema gravar seu historico [ate 'perfeicao'] importante... mais quando ao eficiencia? qual eh mais eficiente; bancos separados, ou 'apenas' tabelas nomeados atravbez de parametros  (em lugar de estes serem colunas num tabela): bancos - tabelas - colunas...

so pensando alto...

0le

[Prof. Baco]

É um caso a refletir sobre o seu pensamento :D

Achei muito interessante este bate-bapo. Achei até um pouco polêmico, devido a grande diversidades de opniões sobre um único tema: DEIXAR OU NÃO O BANCO UNIFICADO.

Cada um tem uma opinião, vou analisar o melhor caso, pois tenho que pensar em uma saída onde o sistema não me dê dor de cabeça e o custo futuro não seja tão grande.

Acho que valeu e muito este "bate-bola" sobre este tema e sei que tem muito mais o que discutir.

Atenciosamente,

Prof. (Baco) Edmar Carvalhaes
Consultor - Professor - Programador Client/Server

edmarca...@gmail.com
SomarTech Tecnologia e Serviços ME
Consultec Tecnologia e Serviços ME

+55 (62) 8140-0462

[MarceloMF]

Bom dia!

Dai uma passada de olho na thread procurando por key words que acho importante nesta temática e não achei, então desculpem caso eu seja redundante.

Nada impede que o seu MER tenha tabelas compartilhadas entre os seus clientes, isso esta alinhado com o modelo multi-inquilino(multi tenanty) bastante utilizado em SAAS, dei uma passada de olho aqui: http://data.ime.usp.br/sbbd2012/artigos/pdfs/sbbd_shp_21.pdf parece um bom texto.

Utilizar várias bases de dados não significa muito trabalho, pois nada impede de scriptar tudo, trabalhar com rollback e etc.

Outros conceitos como database federation e patition table(mysql e postgresql possuem suporte) são importantes na decisão de como você irá fazer isso.

Acredito que exista coisas mais abstratas e até produtivas que OO, sempre viajo quando vou tentar entender dialetos LISP Oo. Talvez algum dia consiga estudar erlang, haskell, clojure e etc... e formar uma opinião melhor quanto a "melhor lang para isso ou para aquilo" "melhor paradigma para isso ou para aquilo outro", mas claro, formamos opiniões dentro da nossa esfera de conhecimento.

[]s

Em 25 de fevereiro de 2015 02:47, Ole Peter Smith <ole...@gmail.com> escreveu:

--

Att, Marcelo M. Fleury

[Marcel Ferrante]

Baco,

depois tenta sistematizar sua conclusão, com um tabela comparativa com vantagens/desvantagens e o q motivou sua decisao.

Abs

Marcel

[Prof. Baco]

Bom galera com base no que conversamos, acho interessante darem uma olhada. Montei esta planilha para que a gente possa dar nossa opnião e eu poder fazer um levantamento para todos e para que todos possam ver também qual a tendência de cada um.

Segue o link do formulário sobre este tema, que achei muito interessante, por sinal: Não estou pedindo nome de ninguém então podem ficar tranquilos... :D

http://goo.gl/forms/irhuZL6XgW

Atenciosamente,

Prof. (Baco) Edmar Carvalhaes
Consultor - Professor - Programador Client/Server

edmarca...@gmail.com
SomarTech Tecnologia e Serviços ME
Consultec Tecnologia e Serviços ME

+55 (62) 8140-0462

[Prof. Baco]

Galera, neste grupo de discussão, tivemos mais de 30 interações e resolvi montar um formulário para fazer uma análise e mostrar para todo mundo, mas a questão é que só obtive duas respostas. Segue link do formulário;

http://goo.gl/forms/irhuZL6XgW

Respondam aí, pois aí vai servir de comparação para um monte de gente. Aguardo retorno de todos.

Atenciosamente,

Prof. (Baco) Edmar Carvalhaes
Consultor - Professor - Programador Client/Server

edmarca...@gmail.com
SomarTech Tecnologia e Serviços ME
Consultec Tecnologia e Serviços ME

+55 (62) 8140-0462

[Ole Peter Smith]

Ja!

Ole, via celular

[Marcel Ferrante]

boa estruturacao, respondi tb

[George Mendonça]

Discussão top hein! Muito bom!

Trabalho com integração de dados, ETL, Big Data, BI e etc., a um bom tempo e talvez posso contribuir um pouco.

Baco considere a visão de todos, cada um tem suas razões, visões, experiência e tal, portanto considere cada um e tome a decisão que achar mais viável, afinal, você conhece o sistema que criou. 

A dica que eu dou  é a seguinte:

1. Se o negócio é o mesmo, mesmo sistema para um negócio único, utilize uma mesma instância.
2. Se o são negócios distintos. Separe uma instância para cada um.
3. Se o sistema é o mesmo para vários negócios distintos (acho que este é o caso pelo que entendi!), separe também! Não faça na mesma instância, pois apesar de ser "o mesmo sistema" são para atender negócios diferentes para diferentes empresas, principalmente porque você certamente vai adaptar cada um para atender ao negócio de cada empresa.

Se o item 3 realmente é sua realidade, separe, pois quanto mais cruzar estas informações para negócios diferentes, mais você estará aumentando os riscos de gerar instabilidade em ambos!

Abraço!

____________________________________________________________

 George Mendonça - "Todo conceito é compreendido quando amado."

 Análise de sistemas, gestão, entusiasta de software livre e professor

 http://lattes.cnpq.br/1805397478061492

 Coordenação FLISOL DF 2015 (FLISOL DF 2015)

____________________________________________________________

 (061) 9287-0130 / (061) 3629-3790

 www.georgemendonca.com.br  - Twitter - Facebook
____________________________________________________________

[Prof. Baco]

Valeu George, eu estava pensando exatamente sobre isto mesmo, separar por ter clientes diferentes.

Galera só tenho 10 respostas até agora, gostaria de mais opiniões sobre o assunto pois achei esta abordagem muito interessante. Segue o link novamente, para quem perdeu:

http://goo.gl/forms/irhuZL6XgW

Quero mostrar o resultado para a galera ainda esta semana.

Atenciosamente,

Prof. (Baco) Edmar Carvalhaes
Consultor - Professor - Programador Client/Server

edmarca...@gmail.com
SomarTech Tecnologia e Serviços ME
Consultec Tecnologia e Serviços ME

+55 (62) 8140-0462

[George Mendonça]

Contribuição ralizada!

[Ole Peter Smith]

divide and conquer.... (napoleao) hehehhe.

0le

[MarceloMF]

Não tem mais a ver com a thread, mas achei foda:
http://br.spoj.com/problems/LISP/

".. sugerindo que é melhor gastar mais tempo treinando os desenvolvedores do que discutindo que linguagem deve ser escolhida."

[]s

Att, Marcelo M. Fleury

[Maykonn Welington Candido]

Um único database MySQL aguenta com sobras quando bem projetado. 

Quando seu sistema se tornar um sucesso extraordinário faça uso de cache, para isso existe Redis, Memcached, etc. Não coloquem a culpa da arquitetura e engenharia no banco de dados(se bem projetado).

Quando tiver muitos clientes pense em um AWS RDS. Fornece bkp de 1 hora atras, se não me engano até menos, a qualquer momento se você quiser, pode provisionar IOPS, escalar, HD, RAM, Processamento, clusterização, etc, e é extremamente barato e simples de configurar, basta criar um database lá, rodar o script sql em seu programa visual de db para criar as tabelas, ou pelo console mesmo e então apontar seu sistema pra consumir o endereço do RDS ao invés do seu localhost, como você faria em qualquer outro servidor.

Vejo todos os dias pessoas reclamando que seu banco está lento e não sei mais o que, mas 10% das vezes ou é o projeto do banco que é uma zoera ou 89,999% a arquitetura do sistema o resto são coisas realmente complexas.

Se precisar exportar dados de  um cliente apenas, você precisa criar um painel administrativo para isso, deve-se evitar tocar no banco de dados ao máximo, você tem um sistema para fazer isso para você. Pense ter de escrever scripts sql e mover bkps toda vez que precisar fazer isso, é um terror sem fim com grande chance de dar merda.

O wordpress usa tabelas separadas pois cada blog, site, sistema feito nele pode possuir uma regra de negócio diferente, tabelas com colunas diferentes, cada sistema num mesmo wordpress, pode portanto, ter um design de database diferente, por isso possui tabelas wp_1_user por exemplo, e mesmo assim isso é horrível, mas no caso do wp que é usado 99% das vezes para coisas muito simples, é viável, mas algo porco e serve para contornar problemas com servidores de bancos de dados compartilhados.

No seu caso, será o mesmo sistema para muitos clientes, portanto o mesmo design de database para todos.

Alguém disse que ter vários clientes na mesma database é ruim pois pode um cliente ter 10 milhões de registros e outro 10 o que reduziria a performance do pequeno - isso não faz sentido quando se tem um desenho de database - mas gente ainda em 2015 tem gente usando servidores de banco de dados compartilhados.... e como você acha que é nesses servidores? Sempre vai ter um cliente grande e um pequeno.

O que você precisa Baco é de um bom projeto e não terá problemas por 20 anos.

Atenciosamente,

Maykonn Welington Candido

Em 2 de março de 2015 09:53, Ole Peter Smith <ole...@gmail.com> escreveu: