AJUDA Arquivo de conexão dinâmico!

[wilvp 0]

Olá, estou quebrando a cabeça a dois dias para fazer um arquivo de conexão dinâmico, veja o que já tentei!

-Usar GET, todas as paginas passar o id geral ex: ../config.php?id=2 ai o arquivo pegaria esse id que seria o nome da database do cliente ex: db_$id (2) SEM SUCESSO

-Usar uma pasta por id, ao criar o projeto o php cria uma pasta nos arquivos de configuração com o id do envio sql ex: ../2/config.php e no php tentei colocar em uma variavel que a db deveri ser o nome da pasta atual ex: db_pasta atual SEM SUCESSO

-Tentei fazer campos no painel admin para preencher os dados da config SEM SUCESSO

Agora não sei como fazer, preciso muito disso

Segue meu arquivo de configuração:

<?php
$host = "localhost";
$user = "usuario";
$pwd  = "senha";
$db   = "db_database";

$con = mysql_connect($host,$user,$pwd) or die("<script language='javascript' type='text/javascript'>;window.location.href='404.php';</script>");
mysql_select_db($db,$con) or die("<script language='javascript' type='text/javascript'>;window.location.href='404.php';</script>");

?>

Alguém pode me dar uma LUZ!

[ESerra 744]

Vamos começar do básico, exatamente qual a justificativa disso tudo?

Pois francamente, parece que existe algum problema na própria estrutura que você criou para o sistema.

[wilvp 0]

Ok, é uma rede de comunidades, a comunidade tem o formato dominio/comunidade/principal.php?id= id da comunidade

quando essa pagina é carregada ela faz um select pegando o nome e o rank do usuario, as categorias e topicos e outros dados, como um forum do forumeiros por exemplo.

o que consegui fazer!

Usando o id passado na principal.php ele requisita o arquivo de config em functions/config/ id passado /config.php

E tem uma pagina no painel adm que cria uma pasta em functions/config/ id da comunidade /config.php com o id da comunidade e um arquivo de config ja configurado, porem queria algo mais dinamico pois as database é no formato db_ id da comunidade e com um arquivo apenas que usasse o id passado por get para pegar a database seria mais pratico

ex:

<?php
$idgeral = $_GET['id'];
$host = "localhost";
$user = "usuario";
$pwd  = "senha";
$db   = "db_$idgeral";

$con = mysql_connect($host,$user,$pwd) or die("<script language='javascript' type='text/javascript'>;window.location.href='404.php';</script>");
mysql_select_db($db,$con) or die("<script language='javascript' type='text/javascript'>;window.location.href='404.php';</script>");

?>

[AndersonMamede 88]

Você já analisou a possibilidade de trabalhar com apenas 1 banco para todas as comunidades? Dá uma pesquisada em termos como "single database or multiple databases" ou "multi-tenant" para ver vantagens/desvantagens e qual tipo de estrutura é melhor para o seu caso.

Mas da forma que você está fazendo atualmente... você pode criar um banco de dados central para armazenar as configurações das comunidades, então quando você receber o id da comunidade, você busca nesse banco central as configurações dela. Fica até mais fácil para você ter um controle e também fazer manutenção nisso, já que você pode criar uma tela para ver/adicionar/alterar uma configuração.

[wilvp 0]

Você já analisou a possibilidade de trabalhar com apenas 1 banco para todas as comunidades? Dá uma pesquisada em termos como "single database or multiple databases" ou "multi-tenant" para ver vantagens/desvantagens e qual tipo de estrutura é melhor para o seu caso.

Mas da forma que você está fazendo atualmente... você pode criar um banco de dados central para armazenar as configurações das comunidades, então quando você receber o id da comunidade, você busca nesse banco central as configurações dela. Fica até mais fácil para você ter um controle e também fazer manutenção nisso, já que você pode criar uma tela para ver/adicionar/alterar uma configuração.

O problema seria o volume de dados, imagine 200 comunidades com 3.000 tópicos, e para fazer um backup individual rsrs

[AndersonMamede 88]

Pois é, tem vantagens e desvantagens, aí você tem que analisar e ver qual é melhor para o seu caso...

[ESerra 744]

O problema seria o volume de dados, imagine 200 comunidades com 3.000 tópicos, e para fazer um backup individual rsrs

Esses números não representam nada, já tive que fazer backup de alguns gigas, usando as ferramentas corretas você faz isso com a mesma facilidade que usa um phpmyadmin no localhost.

Pois é, tem vantagens e desvantagens, aí você tem que analisar e ver qual é melhor para o seu caso...

Existe o certo e a gambiarra... toda solução correta já trás tudo consigo.

[Mateus Silva 64]

Como o Serra disse, números não querem dizer nada, se ficar com dó de usar banco de dados nem use hahah, isso aí que tu disse é pura gambiarra! Faça do jeito certo que vai te dar menos problema.

[Williams Duarte 431]

Ok, é uma rede de comunidades, a comunidade tem o formato dominio/comunidade/principal.php?id= id da comunidade

<?php
$idgeral = $_GET['id'];
$host = "localhost";
$user = "usuario";
$pwd  = "senha";
$db   = "db_$idgeral";

$con = mysql_connect($host,$user,$pwd) or die("<script language='javascript' type='text/javascript'>;window.location.href='404.php';</script>");
mysql_select_db($db,$con) or die("<script language='javascript' type='text/javascript'>;window.location.href='404.php';</script>");

?>

01 Banco * 01 Problema = 1 problema a ser resolvido.

200 Bancos * 1 Problema = 200 problemas a serem resolvidos.

Bancos consagrados como Postgres 9.5, MySQL 5.7, resolve tranquilamente seu problema, mais facil você aprender primeiro a trabalhar com indices, partições e replicação do ficar criando bancos sem saber se tem a real necessidade disso. A primeira opção o "Postgres" apesar de ser OpenSource não é para amadores. Existe foruns Gigantes que usa uma unica base de dados. Varios bancos se usa quando se quer manter a integridade de dados de clientes e versões distintas de software, mas quando se coloca uma conexão desta ai acima, é sinal que voce ainda esta apenas começando, então comece pelo basico, estude como modelar um banco com indices.

[AndersonMamede 88]

Banco de dados separados não é gambiarra (quando feito da forma correta); é apenas uma arquitetura diferente.

Normalmente um único banco compartilhado ("multi-tenant") é o mais indicado, mas existem casos (que não é o dele) em que bancos separados ("single-tenant") se encaixa melhor, sendo que ambas arquiteturas tem prós e contras.

Eu concordo que no caso dele o melhor é um único banco compartilhado, e foi por isso que eu toquei no assunto e sugeri para que ele pesquisasse por essa questão de arquitetura, assim ele entenderia o porquê de fazer de tal forma.

https://axerosolutions.com/blogs/timeisenhauer/pulse/146/single-tenant-vs-multi-tenant-business-software

https://blogs.sap.com/2015/07/12/multi-tenant-vs-single-tenant-architecture-saas/

https://www.crmswitch.com/buying-crm/single-tenant-crm-vs-multi-tenant-crm/

http://cloudtweaks.com/2013/01/single-tenant-vs-multi-tenant-cloud-erp/

https://blog.vision33.com/cloud-erp-single-tenant-vs-multi-tenant

[ESerra 744]

Banco de dados separados não é gambiarra (quando feito da forma correta); é apenas uma arquitetura diferente.

É mesmo, qual foi a sua frase mesmo?

Pois é, tem vantagens e desvantagens, aí você tem que analisar e ver qual é melhor para o seu caso...

[AndersonMamede 88]

É mesmo, qual foi a sua frase mesmo?

Esta?

Você já analisou a possibilidade de trabalhar com apenas 1 banco para todas as comunidades? Dá uma pesquisada em termos como "single database or multiple databases" ou "multi-tenant" para ver vantagens/desvantagens e qual tipo de estrutura é melhor para o seu caso.

Perguntei sobre o uso de apenas 1 banco de dados para todas as comunidades e ainda sugeri que ele estudasse sobre essa questão, assim ele iria aprender e chegaria à mesma conclusão que nós.

[ESerra 744]

Você afirmou que existem "vantagens e desvantagens", pois bem, gostaria de saber quais são as vantagens em usar o que o usuário citou. E também quais são as desvantagens em usar o jeito correto.

[AndersonMamede 88]

Minha mensagem e sugestão foi em relação à questão da arquitetura: banco de dados compartilhados (multi-tenant) vs banco de dados separados (single-tenant). Eu sugeri que ele pesquisasse sobre isso, e a resposta dele foi sobre algo que não está tão diretamente relacionado (em relação ao volume de dados), o que me fez pensar que ele não pesquisou. Já que ele não quis pesquisar, eu apenas dei uma resposta genérica (falando que existem vantagens e desvantagens; uma rápida pesquisa no Google já dá para encontrar).

Nos endereços que mostrei acima fala um pouco sobre as vantagens e desvantagens de cada arquitetura, mas posso colar algumas aqui:

(vantagens do single-tenant; claro que também existem desvantagens)

Some advantages of a single-tenant:

- Maximum privacy: since there is only one instance for a user, there's less risk of another business either accidentally or through corporate espionage snooping on data that doesn't belong to them.

- It's impossible to affect someone else's tasks.

- Better control over upgrades. Upgrades can be can be performed at your own discretion.

- Single tenant systems are easier to back up and restore since each client database has its own separate back up.

(desvantagens do multi-tenant; claro que também existem vantagens)

Multi-tenant disadvantages:

- Since multiple tenants run their applications off the same base, individual users have less ability to customize the applications to their specific needs.

- Updates could be deployed to your business without your authorization as you are relying on the same code base as the other users.

No link abaixo tem o caso de uma aplicação no estilo "rede social empresarial" onde optaram por single-tenant. Eles falam sobre vantagens e o porquê da escolha:

https://axerosolutions.com/blogs/timeisenhauer/pulse/146/single-tenant-vs-multi-tenant-business-software

Eu também já tive um caso em que a equipe optou por single-tenant. Foi em um sistema estilo SaaS para gerenciamento e relatórios de logs e acessos de servidores de proxy Squid. Algumas empresas chegam a ter mais de 1 milhão de novos registros por mês, enquanto outras tem beeem menos. Colocando na balança toda a questão de infraestrutura, custo de negócio, escalabilidade, performance, disponibilidade, backup, etc, optamos por single-tenant.

Mas enfim, como ele está/estava tentando usar uma arquitetura que não é indicada para o caso dele, achei importante que ele pesquisasse sobre isso para aprender e poder distinguir por contra própria quando e o porquê de usar a arquitetura X ou Y, porque não existe uma única arquitetura em que se pode dizer que é certa para absolutamente todos os casos e o resto é gambiarra.

[ESerra 744]

Bom, essa discussão já foi longe demais, cada um que tire as próprias conclusões, hoje em dia não perco mais tempo discutindo com "especialista de ctrl/c-ctrl/v".