Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Salve Brother´s!!
Por você´s serem mais profissionais e experientes do que eu, gostaria de tirar uma dúvida de minha pratica de programção, pois ontem andei debatendo com um brother que também é programador web e não chegamos a um consenso!!
Vejamos o seguinte código:
<?#funcoes.php function conexao($db){ if($db == "local"){ mysql_connect("locahost", "root", ""); mysql_select_db("test"); }elseif($db == "servidor"){ mysql_connect("locahost", "root", ""); mysql_select_db("test"); } } function numero_um($argumento){ conexao("local"); $q = "SELECT * FROM tabela...."; return true; } function numero_dois($argumento){ conexao("local"); $q = "SELECT * FROM tabela...."; } function numero_tres($argumento){ conexao("local"); $q = "SELECT * FROM tabela...."; } function numero_quatro($argumento){ conexao("local"); $q = "SELECT * FROM tabela...."; }#pagina.php if($pesquisa){ if(numero_um($pesquisado)){ #chamo outra função } }?>Eu sei que o mais certo e correto é programar o PHP orientado a Objetos, estendendo classes e bla, bla, bla, bla! Atualmente administro um sistema desta forma e não tive muitos problemas até hoje e meu outro brother quase quis me puxar pelo colarinho no monitor dizendo que eu iria acabar com o banco de dados (hahaha até hoje não aconteceu, mas me chamou muito à atenção!!!) e gostara de saber o seguinte:
É melhor se programar com funções em sistema para web { independente de cada uma ter uma chamada para o banco de dados } ou atribuir um arquivo de conexão e reutiliza-lo via include para não consumir recursos ?
Aguardo à resposta de vocêis!!
Muito Obrigado!!
[]s
bom se tratando de conexoes no banco tem varios itens que precisa ser revisto
1 por segurança nunca de um acesso ao banco de dados com o usuario com total privilegios, use sempre um usuario limitado, to falando do usuario do mysql
2 você nao percebeu no seu caso ainda nenhum problema porque as conexoes sao pequenas, quando você for fazer um sistema grande exemplo orkut, você precisa pensar bem no modo de conectar, porque o banco tem que ficar o maximo de tempo fechado e só abrir na hora de usar, se você usa-se uma classe de conexao você poderia colocar no construtor da classe a conexao do banco e no destruitor da classe você coloca o comando de fechar o banco, assim ficaria automatico sem você precisar chamar a conexao para abrir e nem se preoculparia em fechar
3 você precisa validar melhor por exemplo uma consulta sql você sempre retorna true, mas precisa testar mesmo se ela deu certo
Opa!!Antes de mais nada, muito obrigado por suas opiniões e experiências!!Fabyo!!!
se você usa-se uma classe de conexao você poderia colocar no construtor da classe a conexao do banco e no destruitor da classe você coloca o comando de fechar o banco
Em um projeto já tivemos este tipo de implementação e chegamos a uma simples conclusão de que isto não seria bem válido, porque ao instanciar o objeto por mais que seja simples ou relacionado ao sistema ele vai consumir recursos do banco de dados e você, bem melhor do que eu, sabe que em performace os usuários tão nem ai, querem que seja rápido, eficaz e funcional (heheheh depois você me diz o que os membros do vivaolinux dizem à você!)Sobre Retorno das funções.... Você está totalmente correto, eu apenas ilustrei algo muito rápido para adicionar à dúvida ao fórum.... minuciosamente, e quem pouco me conhece, sabe que sou chato para estes detalhes (sempre uso if(mysql_num_rows > 0)) hehehehe).Privilégios..... Este foi um fator que me chamou muito a atenção http://forum.imasters.com.br/public/style_emoticons/default/thumbsup.gif . Embora a base de dados tenha os usuário voltaldos somente para operação como INSERT, DELETE, UPDATE e SELECT sempre bom pensar no que pode ou não fazer o cidadão do banco de dados { serviu como conselho! }Vamos dizer que caiu do céu esta situação, mandar o ursolouco fazer manutenção no orkut.... { não vai mudar muita coisa... porque aquele sistema já vem com BAD SERVER por natureza } o que você pode recomendar ?[]s e Valeu pela força!!!
Particularmente, eu prefiro fazer toda a interação com o banco de dados através de objetos. Acho que fica muito mais fácil e lógico... por exemplo, eu tenho minha classe "Database", que extendi da "MySQLDatabase". Se um dia eu mudar o banco pra PostGre, é só eu passar a extendê-la da "PostGreSQLDatabase". Não vou precisar alterar 1 linha sequer no código das páginas.
Como o Fabyo observou, é importante você conectar ao banco de dados somente com os privilégios que irá utilizar. Nunca, mas nunca mesmo conecte com um usuário que tenha todos os privilégios.
[]'s!
uma classe bem feita nao vejo porque ter problema de "consumir recursos", porque a classe sera estanciada somente na hora de usar mesmo, nao é correto estanciar a classe no começo da pagina, iria dar na mesma que fazer uma função errada, minha classe só estancia quando executo a query e fecho em seguida, vou postar um assunto sobre segurança, no manual online ta em ingles e eu tenho offline em portugues:
>
Desenhando Bancos de DadosO primeiro passo é sempre criar o banco de dados, a não ser que você queira usar um de terceiros. Quando um banco de dados é criado, ele é atribuído a um dono, que executou os comandos de criação. Normalmente, só o dono (ou um superusuário) pode faz algo com os objetos naquele banco de dados, e para permitir que outros usuários usem, privilégios devem ser concedidos.
Aplicações nunca devem conectar ao banco de dados como seu dono ou um superusuário, porque esses usuários podem executar qualquer consulta que quiserem, por exemplo, modificar o esquema (ex.: destruindo tabelas) ou removendo seu conteúdo completamente.
Você pode criar usuários de bancos de dados diferentes para cada aspecto da sua aplicação com direitos muito limitados aos objetos do banco de dados. Apenas os privilégios mais necessários devem ser concedidos, e evitar que o mesmo usuário possa interagir com o banco de dados em casos de uso diferentes. Isso significa que se invasores conseguirem acessar seu bando usando credenciais da sua aplicação, eles só podem afetar o banco tanto quanto sua aplicação.
Encorajamos não implementar toda a lógica de negócio na aplicação web (ex.: seu script). Ao invés disso, faça parte no esquema do banco, usando view, triggers ou rules. Se o sistema evoluir, crescerá a vontade de criar novas maneiras de usar o banco, e você terá que reimplementar a lógica em cada cliente separado do banco. Além disso, triggers podem ser usados para lidar com certos campos de maneira automática e transparente, o que permite dar informações quando depurar problemas com sua aplicação ou rastreando transações.
>
Técnicas para Evitar AtaquesVocê pode dizer que o atacante precisa possuir um pouco de informação sobre o esquema de banco de dados na maioria dos exemplo. Você tem razão, mas você nunca sabe quando e como isso pode ser obtido e, se acontecer, seu banco de dados pode ficar exposto. Se você estiver usando um pacote open source publicamente disponível para lidar com banco de deados, que pode pertencer a um sistema de controle de conteúdo ou forum, os invasores facilmente produzem uma cópia de parte de seu código. Também pode ser um risco de segurança se este for for mal desenhado.
Esses ataques se baseam principalmente em explorar falhas no código escrito sem se preocupar com segurança. Nunca confie em nenhum tipo de entrada, especialmente aquela que vem do lado do cliente, mesmo que venha de um combobox, um campo de entrada escondido (hidden) ou um cookie. O primeiro exemplo mostra como uma consulta inocente pode causar desastres.
Nunca conecte ao banco de dados como um super-usuário ou como o dono do banco de dados. Sempre use usuários personalidados com privilégios bem limitados.
Verifique se uma entrada qualquer tem o tipo de dados experado. O PHP tem um grande número de funções de validação de entrada, desde as mais simples encontrada em Funções de Variáveis e em Funções de Tipo de Caracteres (ex.: is_numeric(), ctype_digit() respectivamente) além de usar o suporte à Expressões Regulares Compatível com Perl.
Se a aplicação espera por entradas numéricas, considere verificar os dados com a função is_numeric(), ou silenciosamente mudar o seu tipo usando settype(), ou usar a representação númeria usando a função sprintf(). Exemplo 27-6. Uma maneira mais segura para compor consultas de paginação
<?php
settype($offset, 'integer');
$query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";// por favor perceba o %d na string de formato, usando %s seria inútil
$query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;",
$offset);
?>http://br.php.net/manual/pt_BR/ref.ctype.php
Adicione aspas para cada valor não numérico especificado pelo usuário que será passado para o banco de dados com as funções de caracteres de escape (ex.: mysql_escape_string(), sql_escape_string(), etc.). Se um mecanismo de escape de caracter específico par ao seu banco de dados não for disponível, as funções addslashes() e str_replace() podem ser úteis (dependendo do tipo de banco de dados). Veja o o primeiro exemplo. Como o exemplo mostra, adicionar aspas para a parte estática da consulta não é suficiente, fazendo com que a consulta seja facilmente atacada.
Não imprima qualquer informação específica do banco de dados, especialmente sobre o esquema, custe o que custar. Veja também Relatório de Erros e Funções de Tratamento e Relatório de Erros.
Você pode usar stored procedures e cursores previamente definidas para abstrair acesso aos dados para que os usuário não acessem tabelas ou view diretamente, mas essa solução pode ter outros impactos.
Além disso, você ganha em relatar consultas ou dentro do script ou no próprio banco de dados, se esse suportar. Obviamente, o relatório é para previnir qualquer tentativa danosa, mas pode ser útil para ajudar a rastrear qual aplicação foi atacada. O registro não é útil em si, mas atráves da informação que ele contem. Mais detalhes geralmente é melhor que menos.
Fabyo!!!Velho, não sei onde você conseguiu este tipo de conteudo, mas é muito didatico e mostra uma experiência gigante de programação/ administração de base de dados (seja ela qual for!).Parabéns! Muito bem escrito.Abraço[]s
Caros!Sinceramente não vejo grande interferencia em relação a programar de uma maneira ou outra.Eu utilizo a forma de colocar as conexões em forma de arquivos de conexão. Acho desta forma mais fácil manutenção.Creio que isso não seja uma dúvida, e sim um assunto para se saber de mais pessoas!Espero ter colaborado.