• 0
Sign in to follow this  
.Andreia.

Tópico Para Tutoriais/dicas

7 answers to this question

Recommended Posts

  • 0

Esse site tem algumas coisas interesantes:

http://www.praianet.com/tutoriais/mysql/

uhm, pra quem usa linux e tem algumas dificuldades pra achar coisas compatíveis ^^

MySQL Control Center (http://www.mysql.com/products/mysqlcc/)

Modelagem:

DBDesigner (http://www.fabforce.net/dbdesigner4/)

Cliente web:

phpMyAdmin (http://www.phpmyadmin.net/home_page/)

ps.: Todos são soluções gratuítas.

Share this post


Link to post
Share on other sites
  • 0

Salve,

Segue abaixo um pequeno script para se trabalhar com coluna do tipo timestamp (que representa data e hora) com valor padrão.

--
--  EXEMPLO DE COMO SE TRABALHAR 
--  COM COLUMA TIMESTAMP (QUE REPRESENTA DATA E HORA)
--  COM VALOR PADRÃO NO MYSQL
--
-- TESTADO NO 5.1.40-COMMUNITY
--
-- AUTOR: WELLINGTON RODRIGUES <[email protected]>
--
-- SELECIONA O BANDO DE DADOS TEST
USE TEST;
-- APAGA A TABELA DEMO CASO EXISTA
DROP TABLE IF EXISTS DEMO;
-- CRIA A TABELA DEMO
CREATE TABLE DEMO (
    ID INT(11) NOT NULL AUTO_INCREMENT,
    INFO VARCHAR(255) DEFAULT NULL,
    DATA TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT PK_DEMO PRIMARY KEY(ID)
) ENGINE = INNODB;
-- INSERE INFORMAÇÕES NA TABELA DEMO
INSERT INTO DEMO(INFO) VALUES(NULL);
INSERT INTO DEMO(INFO) VALUES(NULL);
INSERT INTO DEMO(INFO) VALUES(NULL);
INSERT INTO DEMO(INFO) VALUES(NULL);
INSERT INTO DEMO(INFO) VALUES(NULL);
INSERT INTO DEMO(INFO) VALUES(NULL);
INSERT INTO DEMO(INFO) VALUES(NULL);
INSERT INTO DEMO(INFO) VALUES(NULL);
INSERT INTO DEMO(INFO) VALUES(NULL);
INSERT INTO DEMO(INFO) VALUES(NULL);
INSERT INTO DEMO(INFO) VALUES(NULL);
-- RETORNA DADOS DO SISTEMA
SELECT * FROM DEMO ORDER BY DATA DESC;
--

Abraços

Share this post


Link to post
Share on other sites
  • 0

Algumas vezes é necessário fazer o registro do momento em que um INSERT (cadastro) foi feito.

Para fazer isso existe a função now() do MySQL. Essa função pode ser utilizada em um campo de data (DATE, DATETIME etc.). Basta colocar como valor no seu INSERT a função now() (sem as aspas), que ele vai cadastrar a data (ou data e hora, se for DATETIME) do servidor na hora em que o registro foi criado.

INSERT INTO `pessoas`
(`nome`, `data_registro`)
VALUES
('Tiago Passos', now())

Veja esse e outros textos no meu blog: www.tiagopassos.com

Share this post


Link to post
Share on other sites
  • 0

Quem já trabalhou com datas no MySQL sabe que o formato que elas são armazenadas é, algumas vezes, meio inconveniente de se trabalhar. É possível modificar esse formato utilizando de programação (PHP, por exemplo), mas é muito mais simples já trazer a data no formato certo, diretamente do banco.

O banco de dados retorna uma data no seguinte formato: 2010-03-18 00:55;23 ou talvez nesse: 2010-03-18 (sem as horas). Como podemos fazer para que ele já traga no formato desejado, por exemplo: 18/03/2010?

É bem simples. Na hora de fazer o SELECT, utilizamos a função DATE_FORMAT() do MySQL. Ela pega a data no formato original e manipula da forma que você quizer.

Exemplo 1;

SELECT *,date_format(`data`,\'%d/%m/%Y\') as `data_formatada` FROM `pessoas`
Nesse caso, ele pegou a data contida no campo data, converteu para formato DD/MM/YYYY e nomeou o campo com a data formatada para data_formatada. Exemplo 2;
SELECT *,date_format(`data`,\'%d-%m às %Hh%i\') as `data_formatada` FROM `pessoas`

No segundo exemplo o formato mudou para DD-MM às HHhMM, Exemplo: 25/06 às 14h35.

Cada ítem da data tem um identificador, veja abaixo a lista deles;

ID Descrição

%a Nome da Semana Abreviado (Seg a Dom)

%b Nome do mês Abreviado (Jan a Dez)

%c Mês de forma numérica (1 a 12)

%D Dia do mês com o sufixo Inglês (1st, 2nd, 3rd, …)

%d Dia do Mês de forma numérica (01 a 31)

%e Dia do Mês de forma numérica (1 a 31)

%f Micro segundos (000000..999999)

%H Horas (00 a 23)

%h Horas (01 a 12)

%I Horas (01 a 12)

%i Minutos de forma numérica (00 a 59)

%j Dia do Ano (001 a 366)

%k Horas (0 a 23)

%l Horas (1 a 12)

%M Nome do mês (Janeiro a Dezembro)

%m Mês de forma numérica (01 a 12)

%p AM ou PM

%r Horas, 12-horas (hh:mm:ss seguidos de AM ou PM)

%S Segundos (00 a 59)

%s Segundos (00 a 59)

%T Horas, 24-horas (hh:mm:ss)

%U Semana (00 a 53), onde Domingo é o primeiro dia da semana

%u Semana (00 a 53), onde Segunda é o primeiro dia da semana

%V Semana (00 a 53), onde Domingo é o primeiro dia da semana; usado com %X

%v Semana (00 a 53), onde Segunda é o primeiro dia da semana; usado com %x

%W Nome do dia da semana (Segunda a Domingo)

%w Dia da semana (0=Domingo a 6=Sábado)

%X Dia da semana onde Domingo é o primeiro dia da semana, de forma numérica com 4 dígitos, usado com %V

%x Ano da semana, onde Segunda é o primeiro dia da semana, de forma numérica, com 4 dígitos, usado com %v

%Y Ano numérico com 4 dígitos

%y Ano numérico com 2 dígitos

%% Um simples caractérl “%”

%x x, para qualquer “x” não listado acima

Veja esse e outros artigos no meu blog: www.tiagopassos.com

Share this post


Link to post
Share on other sites
  • 0

Hoje venho posta sobre a maravilha dos índices em bancos de dados, e algumas dicas de performance. Coisas que não são levados em conta pelos desenvolvedores menos experientes em bancos, hoje serão comentadas neste post.

Até pouco mais de 3 meses eu não sabia de coisas muito avançadas de banco de dados, visto que nunca precisei, porém com o projeto em que trabalho atualmente, nosso banco de dados trabalha com milhões de registros, tabelas gigantes e temos que agilizar a pesquisa ao máximo, mesmo tendo tantos registros, agora vou passa algumas dicas no qual tive que aprender sozinho com muita pesquisa, juntamente com meu amigo e chefe Davi Pozzi.

Índices é a maravilha por trás dos bancos: Em vários testes, verifiquei que ao indexar campos com muitas requisições, o resultado apresentado em menos tempo(resultados consideráveis de redução), eu ainda não entendo o processo interno que os bancos fazem porém são eficientes.

Evite usar o comando LIKE: Evite ao máximo utilização do comando LIKE pois ao pesquisar várias palavras separadas por % o SELECT pode fica muito demorado. A melhor solução para pesquisas em linguagem natural de várias palavras é utilizar Full Text Search, descrito abaixo.

Nunca utilize * em consultas: Esta dica é extremamente valiosa, vou explicar por que. Os bancos de dados atuais utilizam um 'banco guias' para gerenciamento dos schemas(bancos de dados), no caso do MySQL todas as informações de databases, tabelas e campos são cadastrados em information_schema, quando você utilizar * o banco internamente precisa verificar no information quais os campos da tabela no qual deseja resultados, caso o SELECT tenha JOIN esse processo é feito para todas as tabelas, isso já diminui a performance, principalmente se o banco for compartilhar, onde deverá haver muitas informações no information_schema. Por isso fica a dica, é melhor declarar todos os campos que deseja retorna, NUNCA UTILIZE *.

Conferências de strings grandes, utilize MD5: Caso haja necessidade de fazer uma comparação de string em algum momento do desenvolvimento é aconselhável criar um campo contendo o MD5 da string que deseja pesquisar, associar ao campo um índice do tipo HASH, e fazer comparação. Este processo irá diminui muito o tempo de resposta da query. É claro que este tipo de pesquisa somente é válida para valores que devem ser exatamente iguais, para pesquisa por referencia é necessário usar LIKE ou Full Text Search.

Criar índices compostos em pesquisas com mais de um filtro: Caso haja verificações que utilizam mais de um parâmetro da tabela para filtro, é recomentado a criação de índices compostos pelos itens a serem filtrados, este processo melhora consideravelmente a pesquisa.

Evite uso de JOIN, DISTINCT e GROUP BY: Evite ao máximo utilizar estes processos pois eles gastam muito recurso do servidor para executar em tempo razoável, principalmente o DISTINCT.

Somente utilize índice UNIQUE em último caso: Os índices único são extremamente prejudiciais a performance da tabela visto que a cada INSERT o banco irá verificar todos os registros antes de inserir, por isso somente utilize-o em ultimo caso. NUNCA UTILIZE ESSE ÍNDICE EM TABELAS QUE SÃO MUITO PESQUISADAS.

Abuse das FUNCTIONS e STORED PROCEDURE: Todo processo que puder ser feito pelo banco deve ser feito nele, as funções e procedimentos são bons pois:

* São fáceis de alterar e não requer alteração no código fonte, que muitas vezes pode esta criptografado ou encodado.

* O tempo de resposta do processamento de uma função com dados de banco são incrivelmente mais rápidos que em linguagens como PHP, ASP, Ruby e Java, visto que há necessidade de transmitir os dados para a linguagem para que haja o processamento.

* Que as funções podem ser reaproveitadas em outras linguagens.

Neste caso a dica é: Sempre utilize stored procedure e functions quando for possível.

Tudo que exige muito tempo para processamento, utilize arquivo txt: Basicamente a dica é, tudo que requer mais de 2seg para executar, ou utilize processo distribuído, ou armazene a informações em TXT e crie Jobs para executar atualização deste arquivo, um exemplo deste tipo de abordagem é no site http://www.vigiadepreco.com.br, a quantidade de produtos cadastrados, e o total de lojas do sistema são armazenadas em arquivo texto e atualizada a cada 20min pelo Linux.

Otimização da tabela: Toda tabela que possui índice, e que frequentemente altera ou deleta registros devem ser otimizadas, pelo menos um vez por semana, este processo é demorado e recomendado a ser feito durante a madrugada, no MySQL o comando para otimizar a tabela é OPTIMIZE TABLE.

Full Text Search: Por ultimo a dica extraordinária do meu querido chefe(muito puxa saco não é? kkk). Basicamente este item fala sobre o índice tipo FULLTEXT do MySQL, este tipo de índice possibilita pesquisas de alto nível e alta performance em linguagem natural para campos tipo CHAR, VARCAHR ou TEXT, com isso não é necessário utilização de vários LIKE dentro do query, para mais informações acesse http://dev.mysql.com/doc/refman/4.1/pt/fulltext-search.html.

Bom pessoal é isso, espero ter ajudado

Para mais informações sobre tecnologia, programação e SEO acesse http://vivendonaweb.blogspot.com/

T+

Share this post


Link to post
Share on other sites
  • 0

Hoje vou falar um pouco sobre o Sphinx, ainda estou em estudo sobre mecanismos de full text search, como estou gostando do que estou vendo, venho falar sobre, neste post.

Basicamente o Sphinx é um projeto de otimização de buscas do tipo texto em banco de dados com grande quantidade de conteúdos e registros, o MySQL possui um mecanismo interno de criação de índices tipo FULLTEXT, que ajudam muito em pesquisas tipo texto porém existem mecanismos como o Sphinx que trabalha de forma independente ao banco e possuem alta performance. Lendo o manual do Sphinx analisei as características e são realmente impressionantes:

* Alta velocidade de indexação (Acima de 10 MB/se em CPUs modernas);

* Alta velocidade de busca (Média da consulta abaixo de 0.1 segundo em 2 a 4GB de coleções de texto);

* Alta escalabilidade (Acima de 100 GB de texto, acima de 100 Milhões de documentos em uma única CPU);

* Suporta busca distribuída (a partir da versão 0.9.6);

* Suporta MySQL nativamente (tabelas MyISAM e InnoDB são suportadas);

* Suporta busca por frases;

* Suporta ranking de proximidade de frases, provendo boa relevância;

* Suporta Stemming em Inglês e Russo;

* Suporta qualquer número de campos de documentos (pesos podem ser mudados “on the fly”);

* Suporta grupos de documentos;

* Suporta “stopwords”;

* Suporta diferentes modos de busca (“match all”, “match phrase” and “match any” – desde a versão 0.9.5);

* Interface genérica de XML com a qual é possível simplificar integrações customizadas;

API cliente de busca - pure-PHP.

Além disso o modo de pesquisa Full Text possui duas propriedades interessantes:

Stopwords: São preposições e artigos como: a, o, para e um. Em inglês são palavra como “a, are, an, at, be, do, in, of, the e to”. Como são palavras que são muito repetidas em uma língua, os sites de busca acabam não indexando estas Stop Words. Com isto, a performance de uma página de resposta é muito melhor, pois são menos palavras no banco de pesquisa. Por isso, a inserção destas palavras no texto não faz muita diferença. (Fonte: www.marketingdebusca.com.br)

Stemming: Stem: Origem. Stemming: Lingüisticamente, palavras seguem regras morfológicas que permitem a quem está falando derivar variantes da mesma idéia para evocar uma ação (verbo), um objeto ou conceito (substantivo), ou a propriedade de algo (adjetivo). Normalmente, é possível derivar palavras a partir da mesma origem e significado abstrato de ação e movimento. Stemming faz o processo reverso: ele deduz a origem (stem) a partir de uma palavra completamente sufixada de acordo com sua regra morfológica. Essas regras envolvem sufixos morfológicos e flexivos. (Fonte: http://blog.tink.com.br)

Para baixar o Sphinx acesse http://sphinxsearch.com/.

Bom é isso ai, Obrigado pela atenção

Para mais assuntos relacionados a tecnologia, programação e SEO acesse http://vivendonaweb.blogspot.com/

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this