Blog da Kurole Web Design

Criando as tabelas de usuários e incluindo informações
CODE
create table `usuario` (
idusuario integer unsigned not null auto_increment,
nome varchar(30),
primary key (idusuario)
) engine=InnoDb;

insert into `usuario`
(nome) values
(“Paulo”),
(“Joao”),
(“Maria”);

create table `noticias` (
idnoticia integer unsigned not null auto_increment,
idusuario integer unsigned default 0,
noticia varchar(50) not null default ”,
datahora timestamp,
primary key (idnoticia)
) engine=InnoDb;

Incluindo algumas notícias…
CODE
insert into `noticias`
(idusuario, noticia, datahora)
values
(1, “Morreu o gato da vovó”, “2009/08/01 10:15:20″),
(1, “O ônibus atrasou hoje”, “2009/08/02 12:25:20″),
(1, “Vovó chora no enterro do gatinho”, “2009/08/03 10:35:00″),
(2, “Preço do Trigo abaixa 5%”, “2009/08/01 10:00:00″),
(2, “Aumenta o Consumo de Carne”, “2009/08/06 18:15:00″),
(3, “Encontrada a cura para a gripe A”, “2009/07/31 18:00:00″),
(3, “Procura-se Susan desesperadamente”, “2009/08/04 10:00:00″);

Selecionando a notícia mais recente de cada usuário. Isso, depois,
será uma subquery.

CODE
select max(datahora), idusuario
from `noticias`
group by idusuario

Agora que sei qual é a notícia mais recente de cada usuário,
ligo as notícias e usuários com essa subquery…
Aí vai um exemplo:

CODE
select a.idusuario, a.noticia, a.datahora
from `noticias` as a
inner join
(select max(datahora) as datahora, idusuario
from `noticias`
group by idusuario
) as b
on (a.idusuario=b.idusuario and a.datahora=b.datahora)

Maneiras Corretas de Ordernação!

No Mysql
select * from tabela order by rand()

No SQL SERVER
select * from tabela order by newid()

No PostGreSQL
Select * from tabela order by random()

No Oracle
Select coluna from (select coluna from tabela order by dbms_random.value) where rownum = 1

Em MySQL a sintaxe é:
SELECT campo1, campo2 FROM tabela ORDER BY campo1 LIMIT 50,100

Em Firebase/Interbase a sintaxe é:
SELECT campo1, campo2 FROM tabela ORDER BY campo1 ROWS 50 TO 100

Em MS SQL Server a sintaxe é:
SELECT * FROM (SELECT campo1, ROWNUM qtd_linhas FROM table) WHERE qtd_linhas BETWEEN 50 AND 100;

Em PostgreSQL a sintaxe é:
SELECT campo1, campo2 FROM tabela ORDER BY campo1 LIMIT 50 OFFSET 50

Em ORACLE 8i a sintaxe é:
SELECT * FROM (SELECT * FROM tabela) WHERE ROWNUM >= 50 AND ROWNUM <= 100

Olá pessoal! Neste artigo veremos a última parte da criação de uma replicação entre o SQL Server e o MySQL: a verificação da replicação.

• Passo 8: Verificando a replicação

Após a execução com sucesso do passo 7, que descreve com detalhes a criação do assinante para a publicação, a replicação já está operacional, ou seja, os dados já estão sendo replicados do SQL Server. Para confirmar a replicação, basta executar o comando SHOW TABLES dentro do MySQL e verificar que a tabela MSrepl7, uma tabela auxiliar à replicação, e a tabela TB_MSSQL_MYSQL foram criadas corretamente. Além de verificar a criação das tabelas, podemos enviar uma instrução SELECT para verificar os dados. A Figura 8.1 mostra esta verificação por meio do acesso remoto no Putty, que é um cliente Windows para o SSH instalado no Linux.

Figura 8.1 Verificando as tabelas criadas pela replicação.

Devemos lembrar que a replicação criada é do tipo Transacional e que, neste modo, o MySQL deve apenas receber os dados e não modificá-los. Deste modo, toda a modificação nos dados realizada no SQL Server será replicada em poucos instantes para o MySQL. Para provar esta afirmação, vamos realizar um INSERT, um DELETE e um UPDATE na tabela TB_MSSQL_MYSQL do SQL Server, como a Figura 8.2 mostra.

Figura 8.2. Modificando os dados da tabela TM_MSSQL_MYSQL.

Após executar as três instruções devemos aguardas alguns segundos para verificar se estas modificações já foram replicadas para o MySQL. É importante lembrar que a replicação transacional vai replicar APENAS as três instruções, economizando a banda da rede. A primeira instrução executada no SQL Server faz a inserção de uma nova linha na tabela TB_MSSQL_MYSQL, com os valores 4 para a coluna ID e o caracter D para a coluna NAME. A segunda instrução apaga a primeira linha da tabela, cunho valor da coluna ID é 1. A terceira instrução coloca o caractere A para a coluna NAME na linha em que a coluna ID for igual a 2. Verificando o conteúdo da tabela TB_MSSQL_MYSQL no MySQL por meio de uma instrução SELECT, mostrado na Figura 8.3, podemos verificar que a replicação está funcionado corretamente.

Figura 8.3. Verificando a replicação dos dados no MySQL.

Com isso terminamos de criar a replicação do SQL Server para o MySQL como ela foi especificada. Com este tipo de replicação o MySQL pode ser utilizado como um servidor de backup dos dados, ou até mesmo como uma alternativa de acesso quando o SQL Server não estiver disponível.

Como comentário final gostaria de deixar claro que não devemos pensar em tecnologias de bancos de dados diferentes como inimigas. Esta seqüência de artigos mostrou que não é preciso enxergar o SQL Server vs. MySQL, mas sim enxergar que estas tecnologias podem trabalhar bem em conjunto. Ao invés de encarar diferentes bancos de dados como inimigos, do tipo SQL Server x MySQL, podemos imaginar SQL Server + MySQL, onde os dois bancos de dados colaboram para atender as nossas necessidades.

Um grande abraço e até a próxima pessoal

Olá pessoal. Dando continuidade à seqüência de artigos que ensinam como montar uma replicação do SQL Server para o MySQL, veremos nesta quinta parte como criar a assinatura para a publicação criada na sexta parte.

• Passo 07: Assinando a publicação

Após a criação da publicação, descrita em detalhes no passo 6, devemos criar uma assinatura para esta publicação. O processo de criação de uma assinatura (subcription) geralmente é executado nos assinantes (subscribers), pois devem ser deles a iniciativa de receber os dados. Contudo, na publicação entre o SQL Server e o MySQL, e em todo tipo de replicação que envolve fontes de dados que não sejam o SQL Server, devemos configurar a assinatura diretamente no servidor de publicação.

Para iniciar a criação da assinatura devemos utilizar a janela Create and Manage Publications on PICHILIANI, que é mesma janela utilizada para a criação da publicação. Como descrito no passo 6, para acessar esta janela devemos acionado a opção Wizards… partir do Menu Tools do Enterprise Manager. Na janela de assistentes disponíveis devemos expandir o tópico Replication e escolher a opção Create Publication Wizard e clicar no botão OK. Porém, desta vez já existe a publicação chamada From SQL Server to MySQL, que aparece quando expandimos o nome do servidor. Devemos selecionar a publicação e clicar no botão Push new subscription…, como a Figura 7.1 mostra.

Figura 7.1. Selecionando a publicação From SQL Server to MySQL.

A próxima tela do assistente apresenta a janela de boas vidas, que podemos pular apertando o botão Avançar >. Em seguida, o assistente pergunta qual será o assinante que deseja assinar a publicação. Para que o nome do servidor MySQL, identificado pelo DSN TesteMySQL parece na lista de possíveis servidores devemos seguir corretamente todas as etapas descritas no passo 5, onde habilitamos esta fonte de dados para participar em alguma replicação como assinante. Caso todas as etapas do passo 5 tenha sido seguidas corretamente e mesmo assim a fonte de dados não aparecer nesta segunda janela do assistente de criação de assinatura, basta fechar e abrir novamente o Enterprise Manager.

Nesta segunda tela do assistente devemos selecionar a fonte de dados TesteMySQL (MySQL ODBC 3.51 Driver), que deve estar dentro do item Enabled Subscribers, e clicar no botão Avançar >, como a Figura 7.2 mostra.

Figura 7.2. Selecionando o assinante da publicação.

A próxima tela do assistente pergunta qual é o nome do banco de dados, do assinante, que vai receber os dados da replicação. No nosso exemplo o nome do banco de dados é MSSQL_MYSQL, que foi criado no MySQL no passo 3. Basta digitar MSSQL_MYSQL no campo Subscription database name e clicar no botão Avançar >, como mostra a Figura 7.3, para seguirmos adiante no assistente.

Figura 7.3. Especificando o nome do banco de dados do assinante.

Na próxima tela do assistente devemos configurar a freqüência em que os dados da nossa publicação serão enviados para esta assinatura. Para suportar ambientes onde não há conectividade constante entre o Publicador/Distribuidor o SQL Server permite a criação de um horário pré-determinando e recorrente para o envio de dados da publicação. Nestes casos o SQL Server cria um agendamento específico para o job que envia os dados da replicação para os assinantes.

Como a especificação da replicação que estamos montando diz que os dados devem ser replicados o mais cedo possível, devemos escolher a primeira opção deta tela, Continuously – provides minimal latency between when an action occours at the Publishers and is propagated to the Subscriber, o que indica que a replicação será contínua e a latência será mínima. É importante lembrar que esta opção requer uma conexão constante entre o Publicador/Distribuidor e os assinantes e que esta configuração de latência é específica da assinatura e não da publicação. A Figura 7.4 mostra a opção da opção de menor latência para a assinatura que estamos criando.

Figura 7.4. Configurando a latência da assinatura.

A penúltima tela do assistente de criação de publicação pergunta a respeito do que fazer no início da replicação. Como estamos utilizando uma replicação do tipo Transacional, podemos escolher se desejamos criar a estrutura das tabelas/view do artigo ou não. Como no nosso exemplo criamos apenas o banco de dados no MySQL, devemos marcar a opção Yes, initialize the schema and data e também a opção Star the Snapshot Agent to begin the initialization process imediately. Com estas duas opções marcadas, como na Figura 7.5, ao término do assistente de criação da assinatura a estrutura da tabela TB_MSSQL_MYSQL será criada no MySQL e os dados já começaram a ser enviados continuamente.

Figura 7.5. Configurando a inicialização do schema e dos dados.

Por fim o assistente de criação da assinatura mostra o status do serviço SQLServerAgent, responsável pela execução de jobs no SQL Server. Como todo o processo de replicação do SQL Server envolve jobs, é necessário manter o serviço SQLServerAgente ativado tanto no Publicador como no Distribuidor. No nosso exemplo, o servidor PICHILIANI assume os papeis de Publicador e o Distribuidor e por isso deve manter o serviço SQLServerAgent ativado. A Figura 7.6 apresenta a tela de confirmação de ativação deste serviço.

Figura 7.6. Janela de ativação do serviço SQLServerAgent.

A última tela do apenas apresenta um sumário do que foi configurado. Ao clicar no botão Finish todas as configurações da assinatura são realizadas e a publicação começa a todo vapor. A Figura 7.7 apresenta a janela de criação da assinatura após o término do assistente.

Figura 7.7. Término do assistente de criação da assinatura.

Com o término do passo 7 a assinatura da publicação está pronta e funcionando. O próximo e último passo envolve a verificação da replicação de dados por meio da execução de instruções no SQL Server e no MySQL.

Um grande abraço e até a próxima pessoal