Publicado em 4 de dez.

Arquivo de conexão dinâmico!

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!

Discussão (14)

Entre ou cadastre-se para participar da discussão

Entrar Criar conta

ESerra· 5 de dez.

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· 6 de dez.

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· 7 de dez.

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· 7 de dez.

>
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.

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

AndersonMamede· 7 de dez.

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

ESerra· 7 de dez.

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· 8 de dez.

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· 8 de dez.

>
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· 8 de dez.

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· 8 de dez.

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· 8 de dez.

É mesmo, qual foi a sua frase mesmo?

Esta?

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· 8 de dez.

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· 8 de dez.

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· 8 de dez.

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".