Page 9 of 9

Bancos de dados Pré-Construídos dentro do SQL Server – Parte 2 – tempdb

O banco de dados tempdb é – como seu nome sugere  – um banco de dados temporário cujo tempo de vida é a duração de uma sessão do SQL Server; quando o SQL Server para, o tempdb é perdido. Quando o SQL Server é  iniciado novamente, o bando de dados tempdb é recriado, totalmente novo, pronto para o uso.

Há mais coisas acontecendo nesse processo, mas antes de mergulharmos nele você primeiro precisa saber para que o banco de dado tempdb é utilizado.

Um banco de dados pode conter informações e estas informações podem estar contidas em muitas tabelas. Você usa comandos e funções para recuperar e manipular estes dados. Entretanto, há ocasiões em  que você deseja armazenar temporariamente certos conjuntos de dados para um processamento posterior – por exemplo, quando estiver passando dados de um procedimento armazenado para outro que será executado logo após o primeiro. Uma opção seria armazenar os dados no banco de dados tempdb. Qualquer tabela temporária criada em um procedimento armazenado ou consulta deve ser colocada no tempdb.

Você pode estar pensando que essa não é solução ideal. Afinal, não seria maravilhoso se as informações temporárias pudessem ser armazenadas em algum lugar fora do banco de dados? Bem, essa não seria bem a situação em que o tempdb deveria ser usado. Ele só deve ser considerado como um espaço de armazenamento transitório.

Ele também é atualizado não só para estar disponível ao desenvolvedor,  mas  o próprio SQL Server o utiliza. Na verdade, o SQL Server usa o tempdb o tempo todo, e quando reinicializamos o programa ele vai querer saber se os trabalhos temporários com que estava lidando  foram excluídos. Afinal, pode ter havido um problema com esse trabalho                                                                     temporário que nos fez reiniciar serviço.

Assim como qualquer outro banco de dados, o tempdb possui restrições de tamanho, e você deve se garantir que ele seja grande o bastante para trabalhar com suas aplicações e com quaisquer informações temporárias armazenadas nelas.

Bancos de dados Pré-Construídos dentro do SQL Server – Parte 1 – master

Como você já deve ter notado, após instalação do SQL Server vários bancos de dados são instalados.

master:

O master é o banco de dados mais importante do SQL Server, portanto, já mais deve ser realizada qualquer tipo de alteração diretamente nesse banco de dados.

Não há nenhum motivo justificável para entrar nas tabelas desse banco de dados e alterar as informações dos registros ou das colunas diretamente. Ha funções do sistema que permitem a alteração construtiva dos dados de uma forma ordenada, e elas devem ser usadas caso você queira  fazer mudanças no banco de dados master. Ele está no coração do SQL Server e, se for corrompido, há uma grande chance de que o programa pare de funcionar corretamente. O banco de dados master contém as seguintes informações fundamentais:

  • Todos logins de usuários, ou papéis,  aos quais os IDs de usuários pertecem
  • Toda a configuração do sistema (por exemplo, informações sobre a classificação dos dados, implementação de segurança, idioma padrão)
  • Os nomes e as informações sobre os bancos de dados do servidor
  • A localização dos bancos de dados
  • Como o SQL Server é inicializado
  • Tabelas especificas dos sistema, que armazenam as seguintes informações (não é uma lista muito extensa)
  • Como cache é usado
  • Quais são os conjuntos de caracteres disponíveis
  • Uma lista de idiomas disponíveis
  • Mensagens de erro e de aviso do sistema
  • Objetos especiais do SQL Server, chamados assemblies  (tabelas de todos os bancos de dados que lidam com objetos do SQL Server e portanto não são especificas do banco de dados master). O banco de dados master é o guarda de segurança  do SQL Server e utiliza as informações anteriores para garantir que tudo seja verificado.

Batch

Um batch SQL é um conjunto de comandos enviados para execução por um cliente conectado ao banco de dados.


Junções (joins) – Inner joins

Um inner join aplica duas fases de processamento lógico de consulta – aplica o produto cartesiano entre duas tabelas de entrada como o cross join e, em seguida, filtra as linhas com base em um predicado que você especifica. Assim como o cross join, os inner joins têm duas sintaxes padrão.

  1.  SELECT E.EMPID, E.FIRSTNAME, E.LASTNAME, O.ORDERID

FROM HR.EMPLOYEES AS E

JOIN SALES.ORDERS AS O ON (E.EMPID = O.EMPID);

No exemplo acima, podemos verificar que não existe a palavra inner  pois a mesma é opcional porque um inner join é o padrão, assim você pode apenas especificar a palavra chave join.

Exemplo usando a palavra inner:

  1.  SELECT E.EMPID, E.FIRSTNAME, E.LASTNAME, O.ORDERID

FROM HR.EMPLOYEES AS E

INNER JOIN SALES.ORDERS AS O ON (E.EMPID = O.EMPID);

A outra forma de se escrever a frase SQL acima é:

  1. SELECT E.EMPID, E.FIRSTNAME, E.LASTNAME, O.ORDERID

FROM HR.EMPLOYEES AS E, SALES.ORDERS AS O

WHERE E.EMPID = O.EMPID;

Podemos observar que no exemplo acima não existe nenhuma cláusula on.



 

Conhecimento Teórico

Você sabe qual significado de SQL ?

SQL significa Structured Query Language. A SQL é uma linguagem padrão que foi projetada para consultar e gerenciar dados em sistemas de gerenciamento de banco de dados relacionais.


Junções (joins) – Cross joins

Logicamente, um cross join é o tipo mais simples de junção. Um cross join implementa somente uma fase de processamento lógico de consulta – um produto cartesiano. Essa fase opera sobre as duas tabelas fornecidas como entradas para junção e produz um produto cartesiano das duas.  Isto é, é feita a correspondência de cada linha de uma entrada com todas as linhas de outra. Assim se você tiver m linhas de uma tabela e n linhas na outra receberá m x n linhas no resultado.

Existem duas maneiras de realizar:

  • SELECT C.CUSTID, E.EMPID

FROM SALES.CUSTOMERS AS C

CROSS JOIN HR.EMPLOYEES  AS E;

  • SELECT C.CUSTID, E.EMPID

FROM  SALES.CUSTOMERS AS C, HR.EMPLOYEES  AS E

Não há nenhum diferença de lógica ou de desempenho entre as duas sintaxes.


Esquema e Objetos

Toda vez que você executa um “SELECT” você pode fazer de duas maneiras.

  1. SELECT * FROM TABELA;
  2. SELECT * FROM ESQUEMA.TABELA;

Seguindo o exemplo acima, você pode acessar o objeto diretamente e o próprio SQL Server resolve o nome do esquema ao qual objeto pertence.

É recomendado que, ao se referir a objetos em seu código, você sempre use os nomes de objetos de duas partes. Alguns custos insignificantes estão envolvidos na resolução do nome do objeto quando ele não for especificado  explicitamente. Por mais insignificante que possa ser, para quê ter esse custo?


 

T-SQL

Tudo sobre Banco de Dados, pretendo postar dicas de como melhorar seu código, novidades, como fazer trigger, procedures ou seja tudo sobre banco de dados irei postar.