Algumas vezes por ironia do destino  é  necessário resetar a senha de root do MySQL.

Caso esse seja seu caso, siga os passos a seguir.

• Pare o serviço  MySQL, e inicie com o modo skip-grant-tables como mostrado abaixo:

/etc/init.d/mysql stop

mysqld_safe –skip-grant-tables &

• Abra o terminal e depois acesse o console do MySQL:

mysql -u root

• Agora vamos setar a nova senha de usuário root:

/etc/init.d/mysql restart

Referência: http://www.thigomes.com/resetando-a-senha-de-root-no-mysql/

Senhores,

Logo que configurei os arquivos do WordPress o mesmo me retornou essa mensagem:

Your PHP installation appears to be missing the MySQL extension which is required by WordPress.

Para resolver isso eu segui esses passos:

• Certifique-se que o MySQL através de:

# /etc/init.d/mysql status

• Se o MySQL não estiver rodando faça:If MySQL is not running, enter:

# /etc/init.d/mysql start

• Se o Banco não tiver sido instalado correto:

# apt-get remove mysql-server

# apt-get install mysql-server

• Veja se o módulo do PHP5 para MySQL está instalado:

# dpkg --list | grep php5-mysql

• Para instala-lo faça:

# apt-get install php5-mysql

• Por fim, restart o apache

# /etc/init.d/apache2 restart

Pronto, esses passos devem resolver seu problema

Enjoy

“SITE ORGANIZADO POR CIENTISTA POLÍTICO FRANCÊS ABRIGA BANCO DE DADOS SOBRE OS GRANDES MASSACRES
DOS ÚLTIMOS CEM ANOS”

História Viva – Bruno Fiuza

“O francês Jacques Sémelin, professor do Instituto de Estudos Políticos de Paris, passou os últimos 20 anos pesquisando a história dos grandes massacres do século XX. Em 2007, essa extensa investigação deu origem ao livro Purificar e destruir – Usos políticos dos massacres e dos genocídios, um estudo comparativo da violência em massa durante o Holocausto, em Ruanda e na Bósnia que foi publicado este ano no Brasil pela editora Difel. Sémelin, no entanto, não se contentou em transformar seu estudo em livro, e agora trabalha em um projeto inédito: a organização de uma enciclopédia virtual da violência em massa no século XX.

Depois de quatro anos de gestação, o site do projeto foi lançado no ano passado. Reunindo material produzido por pesquisadores renomados, a Enciclopédia online da violência em massa pretende oferecer gratuitamente a qualquer usuário da internet um extenso banco de dados com informações sobre genocídios e massacres perpetrados no planeta ao longo do mais violento século da história. O site reúne biografias dos responsáveis…” (Leia e comente)

Esses dias trabalhei firme no meu mapeador para MongoDB, o MongoParadigm. O código dele, como sempre, está disponível no GitHub. Atualmente estou me esforçando para integrar ele com Rails, e depois disso tudo pretendo finalmente implementar o “has :many” e o “belongs_to”. Pensei como seriam essas associações, e percebi que elas era a parte menos importante do MongoDB.

Isso porque eu acho que estou entendendo o que exatamente é uma base de dados orientada a “documentos”, finalmente – trabalhando na UFABC, é fácil de ver esse tipo de coisa: O registro de um aluno é um documento (no caso, de uma pessoa). O histórico do aluno é outro documento – e essa é a parte interessante, o histórico é um documento que pertence a um aluno, e não o contrário. Isso deve ficar bem documentado no MongoDB, porque apesar de não parecer, as bases de dados relacionais levam a gente a pensar de forma não-natural. Por exemplo, quando você vai armazenar um histórico de notas de um aluno em uma base relacional, normalmente você não armazena UM histórico, e sim um monte de registros que estão ligadas a um aluno por uma chave. Agora, é perfeitamente simples de entender porque o MongoDB não implementa trasações – afinal, no caso dele, se fosse necessária uma alteração se está mexendo em UM documento, e não em 20 registros, por exemplo.

Ainda tenho algumas dúvidas sobre como implementar tudo isso (e também, como ligar isso ao Rails – formulários deveriam ser revistos, porque todos sabemos que o Rails nunca pensou, por motivos óbvios, em atributos multi-valorados). Por exemplo, não há saída fácil para cadastrar uma estrutura como a que segue, no Rails:

{
  nome_disciplina: "Linguagem de Programação",
  horarios: [
    { dia_semana: "segunda", inicio: "10:00", fim: "12:00" },
    { dia_semana: "terça", inicio: "08:00", fim: "09:00" },
  ]
}

Isso, porque o Rails não prevê uma maneira de fazer os horários, por exemplo. Nomear os “input fields” como horarios[][dia_semana] às vezes dá bagunça, e não vejo uma maneira fácil de integrar com o “form_for”, por exemplo. Além disso, tem as validações: eu preciso de alguma forma dizer que a validação é da seguinte maneira: se o Array “horários” for vazio, dá erro. Agora, se ele tiver elementos, deve iterar nesses elementos e ver se o primeiro elemento possui “dia_semana” válido, “início” válido… e também não vejo uma maneira fácil de fazer isso.

Mas acho que esse é o menor dos problemas. O que eu preciso fazer é dar uma maneira de integrar o MongoParadigm com o Rails – Fixtures, Migrations (embora ele seja Schemaless, não significa que não seja possível fazer Migrations – bem ou mal, acredito que existirão momentos não muito raros em que precisaremos transformar um Documento que foi pensado de um jeito em um outro formato), e até mesmo um rake db:fixtures:load ajudaria bastante. Depois disso, associações – isso porque, é tão simples esse modelo que na verdade não vejo muito uso para associações. Por exemplo:

Hoje temos: Aluno pertence a Pessoa, que tem muitos Perfis através de PerfisPessoa, que tem muitas Diretivas de Acesso através do DiretivasPerfil. Só nesse caso, é uma associação 1 para 1, e duas associações Muitos para Muitos. Se eu precisar de uma nova associação, provavelmente vou fazer da seguinte forma: Uma pessoa (que contém aluno) tem muitos Perfis (a foreign-key, digamos assim, fica guardada no próprio documento de Pessoas) e o Perfil possui muitas Diretivas (de novo, o Foreign-key fica em Perfil). Eu elimino 3 tabelas nesse caso, e ainda de graça ganho algumas vantagens que eu não tenho no meu modelo atual: eu posso buscar quais Perfis possuem duas Diretivas específicas, por exemplo. A busca é simples, portanto dá pra viver sem ela por um tempo.

E principalmente – o MongoParadigm funciona como se fosse um Hash do Ruby. Na verdade, é mais ou menos uma mistura entre o Hash e o OpenStruct, mas menos flexível que o segundo e mais flexível que o primeiro. Para todos os efeitos, é um Hash normal, mas tem o “save” e o “update_attributes” que todos os railers amam. Também é bom tomar um cuidado especial com o “update_attributes!”, porque ao contrário do Rails, ele não é tão inofensivo. Por exemplo:

class Pessoa < MongoParadigm::Document
end

eu = Pessoa.create :nome => 'Fulano', :idade => 30
eu.update_attributes :idade => 10
p eu #Retorna Pessoa: { :nome => 'Fulano', :idade => 10 }

eu.update_attributes! :idade => 10
p eu #Retorna Pessoa: { :idade => 10 }

Ou seja, o segundo caso basicamente apaga todos os outros atributos que você já tinha cadastrado. Acho importante esse caso porque acredito que será útil em alguns registros, mas basta lembrar que não existe (ainda – não sei se definitivamente, mas para falar a verdade não vejo porque incluir) algo que funcione como o “save!” ou o “create!”, ou mesmo o “update_attributes!” do Rails. O único que retorna uma exceção é o “get”, que seria um equivalente ao “find” do Rails (por ID). Mas mesmo o “find” é diferente porque ele busca de uma maneira mais “MongoDB” e menos “SQL”.

Agora, porque essas diferenças? Simples – porque MongoDB não é SQL. Se o MongoDB trabalha bem com Hashes, e o Ruby trabalha bem com Hashes, porque transformar isso em um “registro”, com atributos, foreign-keys, “embedded documents” e outras terminologias quando o documento na verdade é um Hash? Para mim isso não fazia o menor sentido, e por isso comecei esse mapeador. Ele ainda não foi transformado em Gem, mas o código já está bem estável e já pode ser usado em muitos exemplos – embora ainda tenha algumas “arestas” que eu pretendo aparar com a integração com Rails.

Independente de usarem este ou outro mapeador, vale dizer que o MongoDB é um projeto interessante que merece mais atenção do que está tendo – a idéia de MapReduce do CouchDB é bem interessante, e eles pegaram carona legal com o Google (que é um grande defensor deste algoritmo) mas as buscas do Mongo ainda são insuperáveis. Isto, claro, na minha opinião.

Modelo de Dados Relacional

1. Conceitos do Modelo Relacional

- O modelo relacional representa o banco de dados como uma coleção de relações;
- Uma relação pode ser vista como uma tabela ou arquivo;
- Quando uma relação é vista como uma tabela, cada linha é representa uma coleção de dados relacionados;
- Ou seja, pode ser encarada como uma instância de uma entidade ou de um relacionamento;
- Na terminologia do modelo relacional formal, cada linha é uma tupla, o nome de uma coluna é chamado de atributo e uma tabela é chamada de relação;
- Os tipos de dados de cada coluna são chamados domínios;
- Para um domínio é dado um nome, tipo de dado e um formato;

Um esquema de relação é feito de um nome de relação (R) e uma lista de atributos (A1, A2, .., An). Cada atributo Ai é o nome desempenhado por algum domínio D no esquema R. O grau de uma relação é o número de atributos (n) de seu esquema de relação. Uma relação pode ser definida matematicamente como um subconjunto do produto cartesiano dos domínios que definem o esquema R.

2. Características de Relações

- Uma relação é diferente de uma tabela ou arquivo.
- Ordem de tuplas em uma relação. Uma relação é definida como um conjunto de tuplas.
- Matematicamente falando, elementos de um conjunto não têm ordem entre eles.
- Entretanto, muitas ordens lógicas podem ser especificadas para uma relação, embora, pela definição de relação, não exista qualquer ordem. Quando uma relação é implementada como um arquivo, uma ordem física tem que ser imposta.
Ordem de valores dentro de uma tupla. De acordo com a definição de relação dada acima, uma tupla é uma lista ordenada de valores. Nesta situação, é importante a ordem em que os atributos aparecem em um esquema de relação. Entretanto, esta ordem não é realmente importante, desde que seja mantido a correspondência entre atributos e valores.
Valores nas tuplas. Cada valor em uma tupla terá um valor atômico, ou seja, atributos compostos ou multivalorados não são permitidos. Esta é a chamada primeira forma normal. Um valor especial, chamado null, é usado para quando não se sabe o valor do atributo ou o valor não é aplicável.
Interpretação de uma relação. Um esquema de relação pode ser interpretado como um fato (ou assertiva); ou pode ser visto como a representação de entidades ou de relacionamentos; ou ainda, pode ser visto como predicados, neste caso, os valores das tuplas representariam os valores que satisfazem os predicados.

3. Restrições Relacionais

Restrições de Domínio. Especifica que o valor de cada atributo A deve ser um valor atômico do domínio dom(A).
Restrições de chave. Por definição, todos os elementos de um conjunto são distintos. Consequentemente, todas as tuplas em uma relação devem também serem distintas. Isto significa que não deve existir duas tuplas com a mesma combinação de valores para todos os atributos. Usualmente, existem outros subconjuntos de atributos com a mesma propriedade acima, que são chamados super-chave, que especifica a restrição de ser único. Toda a relação tem, no mínimo, uma super-chave que é a junção de todos os atributos. Uma super-chave pode ter, entretanto, atributos redundantes (ou seja não necessários para serem únicos). Um conceito mais útil é o de chave, que é uma super-chave com a propriedade de que se eliminarmos qualquer atributo leva a um conjunto de atributos que não mais é uma super-chave. A restrição de ser única é para todo o estado da relação no esquema, ou seja, deve ser atingida mesmo quando novas tuplas são inseridas na relação. Se uma relação tem mais de uma chave, estas são chamadas chaves candidatas. Uma das chaves candidatas é designada chave primária.
Restrição de nulo. Pode ser especificado se valor nulo pode ou não ser permitido.

4. Bancos de Dados Relacionais e Esquemas

Um banco de dados relacional contem muitas relações e as tuplas (das relações) de alguma forma estão relacionadas.
Um esquema de banco de dados relacional é um conjunto de esquemas de relações e um conjunto de restrições de integridade.
O estado de um banco de dados relacional é um conjunto de estados de relação.

5. Integridade de Entidade, Integridade Referencial e Chaves Estrangeiras

A restrição de integridade de entidade diz que nenhum valor de chave primária pode ser nulo. Esta restrição (assim como a restrição de chave) é aplicada em relações individuais.
A restrição de integridade referencial é especificada entre duas relações e é usada para manter a consistência entre tuplas das duas relações. Informalmente, a restrição de integridade referencial diz que uma tupla da relação (R1), que refere-se a outra relação (R2), deve referir-se a uma tupla existente em R2.
Uma chave estrangeira especifica uma restrição de integridade referencial entre duas relações R1 e R2, de tal forma que, se um conjunto de atributos FK no esquema de relação R1 é uma chave estrangeira de R1 que referencia a relação R2 se esta satisfaz as seguintes duas regras: (i) Os atributos de FK tem o mesmo domínio que os atributos da chave primária PK de R2, onde os atributos FK são ditos que se referem a relação R2; (ii) Um valor de FK em uma tupla t1 de R1, ou ocorre em uma tupla t2 de R2 ou tem valor nulo.
As restrições de integridade referencial tipicamente vem dos relacionamentos entre entidades representadas pelo esquema de relação.
Uma chave estrangeira pode referir-se a sua própria relação. O relacionamento de supervisão na entidade empregado, por exemplo.
É possível mostrar diagramaticamente as restrições de integridade através de uma seta que liga cada chave estrangeira a respectiva chave primária da relação referenciada.
As restrições de integridade referencial não incluem uma grande classe de restrições mais gerais conhecidas como restrições de integridade semântica. Exemplos dessas restrições podem ser: (a) o salário de um empregado não pode exceder o salário de seu supervisor; ou (b) o número máximo de horas que um empregado pode trabalhar em todos os projetos por semana não pode ultrapassar 40 horas.
Triggers podem ser usados para esta função.
Dois tipos de restrições existem: (i) restrições de estado (ou restrições estáticas); e (ii) restrições de transição (ou restrições dinâmicas). Um exemplo de transição de transição pode ser que o salário de um empregado só pode aumentar nunca diminuir.

6. Operação de Atualização e Violação de Restrições

6.1. Operação de inserção

Provê uma lista de valores de atributos para uma nova tupla que deverá ser inserida na relação R
Pode violar:
Restrição de domínio (valor não correspondente ao domínio especificado)
Restrição de chave (se um valor de chave já existe)
Integridade de entidade (se a chave primária é nula)
Integridade referencial (se o valor da chave estrangeira refere-se a uma tupla que não existe na relação referenciada)
Geralmente o SGBD deve rejeitar uma inserção que viole essas restrições

6.2. Operação de deleção

Pode violar somente integridade referencial.
Ocorre quando a tupla sendo deletada é referenciada pela chave estrangeira de outras tuplas no banco de dados.
Três opções estão disponíveis:
Rejeitar a deleção
Propagar a deleção
Modificar o valor do atributo sendo referenciado, seja colocando o valor null ou colocar um outro valor válido. Se o atributo referenciado fizer parte da chave primária o atributo não poderá assumir valor nulo, senão será violada a restrição de integridade.

6.3. Operação de Atualização

Usada para alterar os valores de um ou mais atributos em uma tupla
Atributos que não são chaves primárias ou estrangeiras, não tem problemas, exceto a checagem de tipos e domínios
Modificar uma chave primária é a mesma coisa que apagar uma tupla e inserir outra em seu lugar. Inserção e deleção se aplica aqui.
Se uma chave estrangeira é modificada, o SGBD tem que garantir que o novo valor refere-se a uma tupla existente na relação referenciada.

Fonte:http://apconcursos.blogspot.com/2007/09/modelo-de-dados-relacional.html

As doze regras definidas por Codd:

·Regra 1 – Todas as info em um BD relacional são representadas de forma explícita no nível lógico e exatamente em apenas uma forma – por valores em tabelas.

·Regra 2 – Cada um e qq valor atômico (datum) em um BD relacional possui a garantia de ser logicamente acessado pela combinação do nome da tabela, do valor da chave primária e do nome da coluna.

·Regra 3 – Valores nulos devem ser suportados de forma sistemática e independente do tipo de dado para representar informações inexistentes e informações inaplicáveis.

·Regra 4 – A descrição do BD é representada no nível lógico da mesma forma que os dados ordinários, permitindo que usuários autorizados utilizem a mesma linguagem relacional aplicada aos dados regulares.

·Regra 5 – Um sistema relacional pode suportar várias linguagens e várias formas de recuperação de info. Entretanto, deve haver pelo menos uma linguagem, com uma sintaxe bem definida e expressa por conj de caracteres, que suporte de forma compreensiva todos os seguintes itens: definição de dados(DDL), definição de “views”(VDL), manipulação de dados (interativa e embutida em programas)DML, restrições de integridade(entidade – NOT NULL, CHECK, , referencial – relacionamentos entre tabelas existentes – FK, semântica – triggers(salário_gerente > salario_ze)), autorizações e limites de transações (begin, commit e rollback).

·Regra 6 – Todas as “views” que são teoricamente atualizáveis devem também ser atualizáveis pelo sistema.

·Regra 7 – A capacidade de manipular um conj de dados (relação) através de um simples comando deve-se estender às operações de inclusão, alteração ou exclusão de dados.(DML – insert, update, delete).

·Regra 8 – Programas de aplicação permanecem logicamente inalterados quando ocorrem mudanças no método de acesso ou na forma de armazenamento físico.((ISOLAMENTO) -MVC BD=model=classe de entidade)

·Regra 9 – Mudanças nas relações e nas views provocam pouco ou nenhum impacto nas aplicações. .((ISOLAMENTO) -MVC – View + Model(relações))

·Regra 10 – As aplicações não são afetadas qdo ocorrem mudanças nas regras de restrições de integridade.

·Regra 11 – As aplicações não são logicamente afetadas qdo ocorrem mudanças geográficas dos dados.(BD distribuídos)

·Regra 12 – Se um sistema possui uma linguagem de baixo nível, essa linguagem não pode ser usada para subverter as regras de integridades e restrições definidas no nível mais alto.

Dentro da area de geoprocessamento vou comentar hooje sobre uma inovação que modificou e muito a tecnologia em geral, os Bancos de dados. Nos tempos de hoje temos uma gama um tanto quando extensa para aplicações de geoprocessamento mas apenas algumas possuem suporte de conexão com um banco de dados, centralizando a informação.

O ganho da utilização de um banco de dados é a unificação de dados e fim das duplicatas. No caso do Geoprocessamento vemos uma melhoria gigantesca. Em um formato antigo, temos softwares Desktops, logo cada usuário produz o que deve e guarda em sua estação local. Se dois usuários trabalham na mesma area, temos dados duplicados e tempo perdido sem necessidade. Não preciso falar sobre o impacto disso em uma equipe de 10, 20 usuários avançado, certo?

Agora com um banco de dados temos a possibilidade de vários usuários utilizando e atualizando os dados em tempo real sem duplicação de dados. A melhor aplicação possível é a utilização da web. Tendo um aplicativo que roda em um browser e conecta com o banco de dados para receber informações, o usuário possui uma disponibilidade e credibilidade dos dados muito superiores Por exemplo, um trabalhador em campo poderá usar seu computador ligado a um modem 3G, entrar no aplicativo de geoprocessamento e manipular os dados longe da base da empresa, aumentando (e muito) a praticidade e a produtividade.

Agora falando em nomes, temos alguns bancos principais como PostGIS (extensão do PostgreSQL) e MySQL Spatial, porém a marca que sempre se destacou foi a Oracle com seus cartuchos Locator e Spatial, as primeiras extensões espaciais de banco de dados. A questão é que os dados guardados são linhas extensas com inúmeras informações porém nada visual. Nestas informações obtemos o tipo de geometria, o(s) ponto(s) demarcado(s), projeção, entre outras informações. No caso do Oracle Spatial, que eu conheço um pouco mais, temos a geometria marcada com numeros: 1 – ponto; 2 – linha ou curva; 3 – poligono; 4 – coleção de objetos; 5 – multiponto; 6 – multilinha ou multicurva; e 7 – multipoligono. Pode parecer estranho para alguns os tipos de 4 a 7, mas são completamente diferentes, por exemplo, um multipoligono seria um condominio de vários blocos, sendo que cada bloco é um poligono porém o condominio inteiro (objeto) é a união de todos os poligonos.

Bom, não quero me estender nem nas questões técnicas, nem nas gerenciais. Mas deixo aqui uma idéia para aqueles que pensam em montar uma base georeferenciada de um jeito mais simples e com uma escalabilidade maior!

Descobrir o que o cliente deseja, como ele compra, quais são suas motivações. Esses são temas que sempre rondam a cabeça dos pesquisadores. E com o avanço da tecnologia, está cada dia mais fácil acertar!

Confira a reportagem exibida no Jornal Nacional.

Acabamos de disponibilizar diversos novos serviços em nosso segmento de cloud computing (computação em nuvem) em nosso portal.

Todos eles estão relacionados a bancos de dados.

Já contávamos com o MySQL Cloud e agora oferecemos serviços Postgres Cloud e Oracle DB Cloud (versão 10g).

Com essas opções, cobruimos praticamente todo o espectro de aplicações que precisam de bancos de dados para funções desde controle de um simples site até aplicações empresariais com grande quantidade de transações e necessidade de alta escalabilidade, alta estabilidade e velocidade, além de granualaridade em configurações.

Todos estes serviços rodam em nossos cluster especializados em bancos de dados, especialmente otimizados para tarefas que envolvem grande quantidade de IO de disco (usamos RAID 5 SCSI), grande quantidade de memória em cada nó e enorme poder de processamento.

Somos capazes hoje, de atender a grandes exigências do mercado corporativo, a custos baixos, aproveitando todo o ganho de escala que a computação em nuvem proporciona.

Alta velocidade na entrega de serviços contratados neste cluster , agilidade na escalabilidade e baixa latência de conexão são outros diferenciais que somos capazes de oferecer dentro de nossa infraestrutura.

Nosso produtos de DB na nuvem agora são:

• MySQL 5 Cloud
• PostgreSQL Cloud
• Oracle 10g Cloud

  Mais dados sobre estes serviços e informações para contratação instantânea em:

http://shop.bsrsoft.com.br/category.php?id_category=15

Oracle

ALTER TABLE "nome_antigo" RENAME TO "nome_novo";

PostgreSQL

ALTER TABLE "nome_antigo" RENAME TO "nome_novo";

MySQL

ALTER TABLE "nome_antigo" RENAME TO "nome_novo";

observe que não há diferenças nas intruções para os SGBD’s Oracle, MySQL e PostgreSQL. Os comandos são os mesmos para os 3 nesse caso.

SQL Server

sp_rename nome_antigo, nome_novo;

Porém, para o SQL Server, utilizamos o procedimento interno “sp_rename”.

espero que lhe  seja útil, =].

até o próximo.

SQL = Structured Query Language. uma linguagem criada na decada de 70 pela IBM em san jose, california, para manipulacao de banco de dados como oracle, firebird, mysql, db2, sqlserver e etc..

primeira implatacao do oracle sql em 1980 inicialmente chamada de SEQUEL. quem definiu os padroes de comandos foi a ANSI ( american national stantard institute ) eles definiram os padroes originais, porem, cada bd possui comandos adicionais.

*caracteristicas da sql: LDD, LMD, LSD.

LDD = linguagem de definicao de dados. esta caracteristica permite a criacao,  alteracao e exclusao de tabelas e indices.

LMD = linguagem de manipulacao de dados. esta caracteristica permite a selecao, insercao, atualizacao e exclusao de dados.

LSD = linguagem de de seguracao de dados. esta caracteristica permite gerenciar o acesso de usuarios a determinadas tabelas mantendo a integridade dos dados.

Nas consultas SQL é possível retornar os dados ordenados de acordo com nossa necessidade. Para isso, utilizamos a claúsula “ORDER BY”.

Ex: Suponha que queremos selecionar os dados da tabela “cliente” porém o resultado deve ser ordenado pelo nome do cliente em ordem crescente. Para isso utilizaremos a seguinte consulta SQL:

————————————————————————————–

SELECT cod_cliente, nome_cliente FROM clientes ORDER BY nome_cliente ASC;

————————————————————————————–
resultado
cod_cliente     nome_cliente
————       —————————————————————-
75852             ANDRÉ BATISTA
01254             ANDRÉ COIMBRA
00024             BRUNA ALMEIDA

No comando acima pedimos para ele selecionar a coluna “cod_cliente” e a coluna “nome_cliente” da tabela “cliente”:

SELECT cod_cliente, nome_cliente FROM clientes

e pedimos para ordernar o resultado pela coluna “nome_cliente” de forma crescente (ASC/ ascendente) :

ORDER BY nome_cliente ASC
Também é possível ordernar o resultado de forma “decrescente” trocando a palavra “ASC” por “DESC”:

————————————————————————————–

SELECT cod_cliente, nome_cliente FROM clientes ORDER BY nome_cliente DESC;

————————————————————————————–
resultado
cod_cliente    nome_cliente
————    —————————————————————-

00024       BRUNA ALMEIDA

01254       ANDRÉ COIMBRA

75852       ANDRÉ BATISTA

Para quem está começando a trabalhar com o banco de dados Teradata e tem dificuldade de encontrar informações sobre as tabelas e sintaxe dos comandos, utilize os próprios comandos de ajuda do banco:

HELP – exibe informações sobre banco, usuário, tabela, view ou macro

HELP DATABASE nome_banco;
HELP TABLE nome_tabela;
HELP VIEW nome_view;
HELP ’sql’; – lista os comandos utilizados no Teradata
HELP ’sql comando’; – exibe a sintaxe necessária para executar o comando

SHOW – exibe a definição dos dados associados a uma tabela, view ou macro

SHOW TABLE nome_tabela;
SHOW VIEW nome_view;
SHOW MACRO nome_macro;

Um problema com o qual me deparei aqui, ao construir um relatório Master/Detail no JasperReports, utilizando o Firebird com o banco de dados, na execução do relatório e do seu sub-Report começou a ocorrer o seguinte erro:
“Error filling print… Unable to get next record.
net.sf.jasperreports.engine.JRException: Unable to get next record. at net.sf.jasperreports.engine.JRResultSetDataSource.next(JRResultSetDataSource.java:99) at net.sf.jasperreports.engine.fill.JRFillDataset.advanceDataSource(JRFillDataset.java:842) at net.sf.jasperreports.engine.fill.JRFillDataset.next(JRFillDataset.java:760) at net.sf.jasperreports.engine.fill.JRBaseFiller.next(JRBaseFiller.java:1078) at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:111) at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:751)

at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:660)

at net.sf.jasperreports.engine.fill.JRFiller.fillReport(JRFiller.java:63) at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:402) at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:234) at it.businesslogic.ireport.IReportCompiler.run(IReportCompiler.java:815) at java.lang.Thread.run(Unknown Source)

Caused by: org.firebirdsql.jdbc.FBSQLException: The result set is closed at org.firebirdsql.jdbc.FBResultSet.checkCursorMove(FBResultSet.java:217)

at org.firebirdsql.jdbc.FBResultSet.next(FBResultSet.java:249) at net.sf.jasperreports.engine.JRResultSetDataSource.next(JRResultSetDataSource.java:95) … 11 more
Print was not filled. Try using an EmptyDataSource…”

a solução para esse problema é bastante simples, e foi encontrada no fórum da JasperForge, na string de conexão do jdbc
adicionar “?defaultResultSetHoldable=True” a url de conexão, por exemplo:
“jdbc:firebirdsql:10.1.1.1:dbPath?defaultResultSetHoldable=True”

O PostgreSQL é um excelente e poderoso banco de dados relacional. A função do banco de dados é extremamente importante na construção de aplicativos, afinal, tudo se resume em entrada de dados, processamento e saída. Mas, para que as informações não sejam desnecessariamente inseridas repetidamente no sistema, ou até reprocessados, essas informações são armazenadas em um banco de dados.

A versão utilizada nesse tutorial é a 8.3.0, que você pode conseguir em http://www.postgresql.org/ftp/binary/v8.3.0/win32. Há uma versão mais nova, a 8.3.4 mas por alguns motivos não pude testar essa versão. Se você puder, o processo de instalação da nova versão provavelmente não deve ser diferente desse.

Após baixar, descompacte os arquivos em qualquer pasta de sua preferência. Entre na pasta onde os arquivos foram descompactados e execute o arquivo postgresql-8.3.msi. Será exibida a tela onde você pode escolher o idioma que será utilizado para exibir as informações de instalação.

Escolha a opção Brazilian Portuguese/Português – Brasil.

Cique no botão Start e será exibido uma tela sugerindo o fechamento de todos os programas.

Clique em Próximo e será exibida uma tela de informações sobre o PostgreSQL.

Clique em Próximo e será exibida a tela de opções de instalação, onde você poderá alterar os diretórios de instalação, bem como os componentes a serem instalados. Não vejo a necessidade de fazer nenhuma alteração nessa tela.

Clique em Próximo e será exibida a tela de opções de configuração do serviço. Novamente, não vejo a necessidade de alterar os valores nesta tela.

Clique em Próximo e você será questionado se deseja criar uma conta para usar o PostgreSQL.

Clique em Sim e será exibida a senha gerada.

Clique em Ok e será exibida as configurações de banco de dados.

Informe a senha e clique em Próximo e será exibida a tela de linguagens procedurais aceita no PostgreSQL.

Deixe selecionado a opção PL/pgsql e será exibida a tela de instalação de módulos.

Sinceramente, nunca precisei alterar nada nessa tela. Clique em Próximo e será exibida a tela de confirmação de instalação.

Caso você tenha certeza que fez as configurações como especificado, clique em Próximo, caso contrário, clique em Voltar.

Será iniciada o processo de instalação.

Após o processo de instalação ser concluída com sucesso será exibida a tela de Conclusão.

Tire a seleção da opção Launch Stack Builder at Exit e clique em Concluir. A instalação está concluída.

Testando se o PostgreSQL está instalado

Para testar se tudo está funcionando perfeiramente siga os passos:

1. Clique no botão Iniciar do Windows;
2. Opção Todos os Programas;
3. Opção PostgreSQL 8.3;
4. Clique em PgAdmin III será carregado o programa e exibido a Dica do Dia. Cliquem em Fechar.

Note que a esquerda há uma lista de Servidores, na verdade apenas 1 servidor “PostgreSQL Database Server 8.3 (localhost:5432)”.

Note também que um ícone com um X em vermelho precede esse servidor. Isso significa que você não está conectado ao servidor.

Para conectar, basta dar um duplo-clique sobre o nome do servidor. Será solicitada a senha do banco de dados, a qual você informou durante a instalação.

Após digitar a senha clique em Ok e o ícone ao lado do servidor mudará e uma lista de componentes será exibida abaixo do servidor.

Ok. O PostgreSQL está instalado e configurado.

Hoje Eu e a Luciane enfrentamos um problema: Realizar um select em um campo datetime do MySql. Parece simples? Mas não foi!

Em nossas consultas sempre realizamos pesquisas no banco de dados com campos do tipo datetime, porém nunca enfrentamos a situação em que o resultado sempre vinha vazio sendo que temos dados em banco. Desta forma começamos a perguntar: Porque o aqua (nossa ferramenta para consultas à banco de dados) não traz o resultado?

Nosso select no aqua era o seguinte:

select * from tabela where campo_data = current_date

Bom, normalmente, para outras consultas esse comando sql funcionaria. Desta vez não foi bem assim.

Dando uma analisada no conteúdo da tabela no banco, identificamos as seguintes datas:

16/11/2009 11:39:00
16/11/2009 10:30:03

Desta forma, podemos identificar que, apesar de serem mesmas datas, o datetime permite gravação de hora, minuto e segundos. Essa foi a primeira pista.

A segundo pergunta foi: Como estão sendo gravados estes dados?

Identificamos que no PHP, na realização do insert em banco de dados, o programador pegou a data atual com o seguinte comando: “now”. Agora temos a segunda pista. O comando “now” do PHP traz a data atual, acompanhada de hora, minuto e segundos! Assim, quando era realizado insert em banco, era gravado a data com a hora atual, porém na busca estavamos utilizando apenas a data. O resultado do SQL era vazio pois a data era a mesma mas a hora não.

Como resolver?

A idéia inicial foi alterar a função PHP de ‘now’ para date(‘Y-m-d’). E deu certo!

Ao utilizar a função “date”, o PHP grava a data no campo, com a hora zerada. Desta forma a consulta sql desconsidera a hora para aquela linha, trazendo o registro. É isso!

Abraço.

No MYSLQ5 as procedures e triggers não vem com o banco por default,há 2 parametros de dump que controlam este comportamento.

* –routines – FALSE by default
* –triggers – TRUE by default

seria assim para enviar as procedures e triggers para o dump assim como os dados e tabelas

mysqldump –routines > outputfile.sql

Dump apenas das storad procedures e triggers sem tabelas e dados:

mysqldump –routines –no-create-info –no-data –no-create-db –skip-opt > outputfile.sql

e para rodar o sql com as procedures executar o comando:

mysql < outputfile.sql

Por causa do MySQL

A história começou em 2008 quando a Sun, de olho no mercado de banco de dados avaliado em US$ 15 bi, comprou o MySQl. Foram pagos 800 milhões de dólares em dinheiro e mais 200 milhões de dólares em troca de ações.

Mas a crise mundial fez os negócios e novos investimentos cessarem e a Sun passou a procurar um comprador enquanto o preço de suas ações despencavam. A IBM se recusava a pagar os 7 bilhões que os acionistas queriam e o negócio paralizado. A esperança era a Sun enfraquecer mais e capitular diante das péssimas condições de mercado.

A Oracle surge do nada e oferece pouco mais de 7 bilhões de dólares, uma rasteira na IBM, e anuncia ao mundo a aquisição da Sun. O governo americano aceita o negócio, mas a União Européia levanta questões sobre concorrência, concentração de mercado e o futuro do MySQL. A suspeita é que a Oracle não irá cumprir a promessa de desenvolver o MySQL e usá-lo apenas para vender o seu produto principal, Oracle Database. Outra suspeita é que o produto será deixado de lado e os consumidores não teriam uma opção. Sabemos que não é verdade, o PostgreSQL é a prova.

Obviamente, a Sun esperava que o negócio fosse aprovado rápido e como isso não aconteceu, vai demitir mais 3000 pessoas, 10% da sua força de trabalho. Essa óbvia perda de talentos faz com que a concorrência, IBM principalmente, aproveite para levar a maior quantidade de clientes possível e com bastante sucesso.

E agora?

É óbvio que um SGBD como o MySQL não pode ficar não mão de programadores de fins de semana. Precisa de uma empresa com recursos financeiros para realizar os invesmentos necessários para a melhoria contínua.

Durante a Oracle Open World, a mensagem foi clara: Sun e Oracle estão juntas. Se o MySQL é o problema, ele provavelmente será descartado através de alguns possíveis cenários:

- MySQL vendido por uma pechincha para uma empresa qualquer de fundo de quintal. Pouco provável.

- Saída Red Hat: MySQL passa a ser um projeto totalmente livre apoiado pela comunidade com uma versão “Oracle MySQL” para empresas.

- MySQL é vendido para um parceiro ou empresa que precisa completar seu leque de produtos. Google, por exemplo, seria uma empresa óbvia. A HP é outra que poderia se beneficiar da venda de servidores otimizados com MySQL.

- Oracle desiste do negócio.

O futuro do MySQL agora é muito mais incerto. As preocupações da UE são válidas, acredito eu, mas eles não oferecem uma solução. A Sun precisa da Oracle, fato. O Exadata 2 foi inclusive otimizado para o softwares da empresa. A perda de talentos e clientes pode deixar a Sun em uma situação insustentável. As opiniões estão divididas e obviamente muitos defensores de software livre gostaram na notícia, outros nem tanto.

Em números de faturamento, o MySQL é pífio, com faturamento de 70 milhões de dólares por ano. Mas ele concentra praticamente metade dos websites, blogs e sistemas de controle de conteúdo da web.

Autoridades européias tem até o dia 19 de Janeiro para bater o martelo, mas se dizem abertos a negociar.

Fonte: Ricardo Bicalho – MeioBit -  http://meiobit.com/meio-bit/ind-stria/ue-n-o-aprova-compra-da-sun-pela-oracle

Nem sempre é fácil fazer uma deleção, então segue abaixo algumas possíveis aplicações do comando DELETE do Oracle.

É isso ai. Espero ter ajudado.