Relação Cluster> Catálogo> Esquema> Tabela

Cluster = Uma instalação do Postgres

Quando você instala o Postgres em uma máquina, essa instalação é chamada de cluster . 'Cluster' aqui não se entende no sentido de hardware de vários computadores trabalhando juntos. No Postgres, cluster refere-se ao fato de que você pode ter vários bancos de dados não relacionados, todos em funcionamento, usando o mesmo mecanismo de servidor do Postgres.

A palavra cluster também é definida pelo SQL Standard da mesma maneira que no Postgres. Seguir de perto o SQL Standard é um objetivo principal do projeto Postgres.

A especificação SQL-92 diz:

Um cluster é uma coleção de catálogos definida pela implementação.

e

Exatamente um cluster está associado a uma sessão SQL

Essa é uma maneira obtusa de dizer que um cluster é um servidor de banco de dados (cada catálogo é um banco de dados).

Cluster> Catálogo> Esquema> Tabela> Colunas e Linhas

Portanto, no Postgres e no SQL Standard, temos esta hierarquia de contenção:

• Um computador pode ter um cluster ou vários.
• Um servidor de banco de dados é um cluster .
• Um cluster possui catálogos . (Catálogo = banco de dados)
• Catálogos têm esquemas . (Esquema =  espaço para nome  (Namespace) das tabelas e limite de segurança)
• Esquemas têm tabelas .
• As tabelas têm linhas .
• Linhas têm valores , definidos por colunas .
  Esses valores são os dados comerciais de que seus aplicativos e usuários se preocupam, como nome da pessoa, data de vencimento da fatura, preço do produto, pontuação máxima do jogador. A coluna define o tipo de dados dos valores (texto, data, número e assim por diante).

Vários Clusters

Este diagrama representa um único cluster. No caso do Postgres, você pode ter mais de um cluster por computador host (ou SO virtual). Geralmente, vários clusters são feitos para testar e implantar novas versões do Postgres (ex: 9.0 , 9.1 , 9.2 , 9.3 , 9.4 , 9.5 ).

Se você tinha vários clusters, imagine o diagrama acima duplicado.

Diferentes números de porta permitem que os vários clusters permaneçam lado a lado, funcionando ao mesmo tempo. Cada cluster receberia seu próprio número de porta. O habitual 5432é apenas o padrão e pode ser definido por você. Cada cluster está escutando em sua própria porta atribuída as conexões de entrada do banco de dados.

Read More

Desinstalar pacotes no debian (pacote e depêndencias)

Instalar um pacote qualquer neste caso o zenity,

Nota: O Zenity é um software que permite criar diversos tipos de caixas de diálogo simples para interação com os utilizadores em um ambiente Linux, que podem ser utilizadas em scripts do shell.

:~$ sudo apt-get install zenity

Para remover o pacote e todas as dependências fazemos

:~$ sudo apt-get purge zenity 

Com o comando acima removemos apenas o pacote zenity, não as dependências instaladas com ele

 Para remover o que ficou a mais e não está a ser usado

:~$ sudo apt-get autoremove --purge

Read More

Mudar nome de Usuários do Windows 10

Fonte: https://answers.microsoft.com/pt-br/windows/forum/all/mudar-nome-de-usuários-do-windows-10/de861aaf-eb87-42eb-8285-2ee836702e62

Se estiver utilizando um Usuário Local do sistema, basta efetuar os processos através das configurações do Windows, seguindo os passos abaixo:

• Pressione as teclas Windows+R.
• Digite control userpasswords2, clique em OK.
• Em Contas de usuário, selecione o usuário e clique em Propriedades.
• Na guia geral, altere o nome que é apresentado no campo Nome de usuário.
• Clique em Aplicar, OK.
• Reinicie o sistema. 

Read More

comandos básicos git

Comandos básicos do git

#iniciar um repositório. Colocamo-nos na pasta que queremos no git e iniciamos com:
$ git init

# adicionar todos os ficheiros da pasta ao git
$ git add .

#Podemos adicionar só um documento ou pasta. Consultar help do git. Neste caso adicionamos tudo

#Fazer commit para guardar no master o conteúdo adicionado ao header
$ commit -m "Qualquer coisa"

# adicionar todos os ficheiros da pasta ao git

$ git config --global core.autocrlf false

# Remover ficheiros e pastas (-r) do index. Ficheiros e pastas físicos não são apagados (--cached). Devemos adicionar um ficheiro .gitignore para que no próximo commit estes não voltem a ser adicionados.

$ git rm -r --cached .

# adicionar dados do utilizador (name) ao config Global
$ git config --global user.name xpto

# adicionar dados do utilizador (email) ao config Global
$ git config --global user.email xpto@gmail.com

# adicionar local do repositório externo ao config local, porque isto é feito por repositório ( namerepo - será o nome do nosso repositório)
$ git config --local remote.origin.url=https://github.com/xpto/namerepo

# Para enviarmos o nosso repositório para o guithub fazemos
$ git push 

Read More

.gitignore

O Git vê todos os arquivos em sua cópia de trabalho como uma das três coisas:

1. rastreado - um arquivo que foi previamente preparado ou confirmado;
2. não rastreado - um arquivo que não foi preparado ou confirmado; ou
3. ignorado - um arquivo que foi dito explicitamente ao Git para ignorar.

Arquivos ignorados geralmente são artefatos de construção e arquivos gerados por máquina que podem ser derivados da origem do repositório ou, caso contrário, não devem ser confirmados. Alguns exemplos comuns são:

• caches de dependência, como o conteúdo /node_modulesou/packages
• código compilado, tais como .o, .pyce .classarquivos
• construir diretórios de saída, tais como /bin, /outou/target
• arquivos gerados em tempo de execução, tais como .log, .lockou.tmp
• arquivos de sistema ocultos, como .DS_StoreouThumbs.db
• arquivos de configuração IDE pessoais, como .idea/workspace.xml

Os arquivos ignorados são rastreados em um arquivo especial chamado .gitignore na raiz do seu repositório. Não há um comando explícito git ignore: em vez disso, o .gitignore arquivo deve ser editado e confirmado manualmente quando você tiver novos arquivos que deseja ignorar. Os ficheiros.gitignore contêm padrões que são comparados com os nomes de arquivo no seu repositório para determinar se devem ou não ser ignorados.

Git ignorar padrões

.gitignore usa padrões de globbing para combinar com nomes de arquivos. Você pode construir seus padrões usando vários símbolos:

padronizar	Correspondências de exemplo	Explicação*
**/logs	logs/debug.log logs/monday/foo.bar build/logs/debug.log	Você pode anexar um padrão com um asterisco duplo para corresponder aos diretórios em qualquer lugar do repositório.
**/logs/debug.log	logs/debug.log build/logs/debug.log mas não logs/build/debug.log	Você também pode usar um asterisco duplo para corresponder aos arquivos com base no nome e no nome do diretório pai.
*.log	debug.log foo.log .log logs/debug.log	Um asterisco é um curinga que corresponde a zero ou mais caracteres.
*.log !important.log	debug.log trace.log mas não important.log logs/important.log	Anexar um ponto de exclamação a um padrão o nega. Se um arquivo corresponder a um padrão, mas também corresponder a um padrão de negação definido posteriormente no arquivo, ele não será ignorado.
*.log !important/*.log trace.*	debug.log important/trace.log mas não important/debug.log	Os padrões definidos após um padrão de negação irão ignorar todos os arquivos negados anteriormente.
/debug.log	debug.log mas não logs/debug.log	O prefixo de uma barra corresponde aos arquivos apenas na raiz do repositório.
debug.log	debug.log logs/debug.log	Por padrão, os padrões correspondem aos arquivos em qualquer diretório
debug?.log	debug0.log debugg.log mas não debug10.log	Um ponto de interrogação corresponde exatamente a um caractere.
debug[0-9].log	debug0.log debug1.log mas não debug10.log	Os colchetes também podem ser usados ​​para corresponder a um único caractere de um intervalo especificado.
debug[01].log	debug0.log debug1.log mas não debug2.log debug01.log	Os colchetes correspondem a um único caractere no conjunto especificado.
debug[!01].log	debug2.log mas não debug0.log debug1.log debug01.log	Um ponto de exclamação pode ser usado para corresponder a qualquer caractere, exceto um do conjunto especificado.
debug[a-z].log	debuga.log debugb.log mas não debug1.log	As faixas podem ser numéricas ou alfabéticas.
logs	logs logs/debug.log logs/latest/foo.bar build/logs build/logs/debug.log	Se você não anexar uma barra, o padrão corresponderá aos arquivos e ao conteúdo dos diretórios com esse nome. No exemplo corresponde à esquerda, os diretórios e os arquivos denominados logs são ignorados
logs /	logs/debug.log logs/latest/foo.bar build/logs/foo.bar build/logs/latest/debug.log	Anexar uma barra indica que o padrão é um diretório. Todo o conteúdo de qualquer diretório no repositório correspondente a esse nome - incluindo todos os seus arquivos e subdiretórios - será ignorado
logs/ !logs/important.log	logs/debug.log logs/important.log	Espere um minuto! Não deve logs/important.logser negado no exemplo à esquerda Não! Devido a uma peculiaridade relacionada ao desempenho no Git, você não pode negar um arquivo que é ignorado devido a um padrão que corresponde a um diretório
logs/**/debug.log	logs/debug.log logs/monday/debug.log logs/monday/pm/debug.log	Um asterisco duplo corresponde a zero ou mais diretórios.
logs/*day/debug.log	logs/monday/debug.log logs/tuesday/debug.log mas não logs/latest/debug.log	Os curingas também podem ser usados ​​nos nomes de diretório.
logs/debug.log	logs/debug.log mas não debug.log build/logs/debug.log	Os padrões que especificam um arquivo em um diretório específico são relativos à raiz do repositório. (Você pode acrescentar uma barra, se quiser, mas ela não faz nada de especial.)

** essas explicações assumem que seu arquivo .gitignore está no diretório de nível superior do seu repositório, como é a convenção. Se o seu repositório tiver vários arquivos .gitignore, substitua mentalmente "raiz do repositório" por "diretório que contém o arquivo .gitignore" (e considere unificá-los, para a sanidade da sua equipe). *

Além desses caracteres, você pode usar # para incluir comentários em seu .gitignore :

# ignore all logs
*.log

Você pode usar \ para escapar dos caracteres padrão se tiver arquivos ou diretórios que os contenham:

# ignore the file literally named foo[01].txt
foo\[01\].txt

Read More