From e88a310d5715ebe0f896f78c9ab91dc5cc012ce0 Mon Sep 17 00:00:00 2001 From: Unknown Date: Tue, 18 Apr 2017 14:52:19 -0300 Subject: [PATCH] optimizing translation --- _includes/sqlstyle.guide.pt-br.md | 99 +++++++++++++++---------------- 1 file changed, 49 insertions(+), 50 deletions(-) diff --git a/_includes/sqlstyle.guide.pt-br.md b/_includes/sqlstyle.guide.pt-br.md index 66bd71d..9606abe 100644 --- a/_includes/sqlstyle.guide.pt-br.md +++ b/_includes/sqlstyle.guide.pt-br.md @@ -10,7 +10,7 @@ alterações ou correções de bugs, por favor abra uma [issue][issue] ou faça Estas diretrizes foram desenhadas em conformidade com o livro [SQL Programming Style][celko] de Joe Celko, para serem adotadas mais facilmente por equipes que já leram o livro. Em relação ao livro, este guia é um pouco mais -opiniativo em algumas áreas, enquanto em outras, é mais relaxado. É certamente +opiniativo em algumas áreas e mais tranquilo em outras. Certamente é mais sucinto que [o livro de Celko][celko], que contém anedotas e racicínios por trás de cada regra. @@ -31,10 +31,10 @@ Baseado no trabalho em [http://www.sqlstyle.guide][sqlstyleguide]. a legibilidade do código. * Armazene informações de data e hora compatíveis com [ISO-8601][iso-8601] (`YYYY-MM-DD HH:MM:SS.SSSSS`). -* Por questões de portabilidade, tente utilizar apenas funções SQL padrão ao - invés de funções específicas de servidores SQL de outros fornecedores. +* Por questões de portabilidade, tente utilizar apenas funções SQL padrão no lugar + de funções específicas de servidores SQL de fornecedores. * Mantenha o código sucinto e desprovido de SQL redundante—como adição de aspas - e parênteses desencessários, ou cláusulas WHERE que podem ser derivadas. + e parênteses desnecessários, ou cláusulas WHERE que podem ser derivadas. * Inclua comentários no código SQL quando necessário. Utilize o estilo C abrindo com `/*` e fechando com `*/` onde possível. Onde não for, preceda os comentários com `--` e termine com uma nova linha. @@ -55,7 +55,7 @@ UPDATE file_system ### Evite * CamelCase—difícil de se analisar rapidamente. -* Prefixos descritivos ou notação Húngara como `sp_` ou `tbl`. +* Prefixos descritivos ou notação húngara como `sp_` ou `tbl`. * Plurais—utilize termos coletivos onde possível. Por exemplo, `pessoal` ao invés de `funcionários` ou `pessoa` no lugar de `indivíduos`. * Identificadores entre aspas—caso necessário, utilize as aspas duplas SQL92 @@ -69,7 +69,7 @@ UPDATE file_system ### Geral * Tenha certeza que o nome é único e não é uma [palavra-chave reservada][reserved-keywords]. -* Matenha o tamanho máximo de 30 bytes—na prática isso são +* Matenha o tamanho máximo em 30 bytes—na prática isso são 30 caracateres, a não ser que esteja utilizando um conjunto de caracateres multi-byte. * Nomes devem começar com uma letra e não devem terminar com underscore. @@ -78,8 +78,8 @@ UPDATE file_system se ler. * Utilize underscores onde você normalemnte incluiria um espaço (primeiro nome se torna `primeiro_nome`). -* Evite abreviações. Se precisar utilizá-las, tenha certeza de que elas - serão amplamente compreendidas. +* Evite abreviações. Se precisar utilizá-las, tenha certeza de que serão + amplamente compreendidas. ```sql SELECT first_name @@ -88,13 +88,13 @@ SELECT first_name ### Tabelas -* Utilize um nome coletivo ou de forma menos ideal, plurais. Por exemplo, +* Utilize um nome coletivo ou menos idealmente, plurais. Por exemplo, (em ordem de preferência) `pessoal` e `empregados`. * Não utilize prefixos com `tbl` ou qualquer outro prefixo descritivo ou notação húngara. * Nunca dê a uma tabela o mesmo nome de uma das suas colunas e vice versa. -* Evite, quando possível, concatenar dois nomes de tabelas para criar o nome de - uma tabela de relacionamento. Ao invés de utilizar `mecanicos_de_carro`, +* Evite quando possível concatenar dois nomes de tabelas para criar o nome de + uma tabela de relacionamento. No lugar de `mecanicos_de_carro`, prefira `servicos`. ### Colunas @@ -102,8 +102,8 @@ SELECT first_name * Sempre utilize nomes no singular. * Quando possível, evite usar apenas `id` como identificador primário da tabela. * Não adicione uma coluna como o mesmo nome da tabela e vice versa. -* Sempre utilize caixa baixa, exceto onde capitalização fizer sentido, como - em nomes próprios. +* Sempre utilize caixa baixa, exceto onde capitalização fizer sentido (como + em nomes próprios). ### Aliasing ou correlações @@ -158,11 +158,11 @@ onde for apropriado. Sempre utilize caixa alta para [palavras-chave reservadas][reserved-keywords], como `SELECT` e `WHERE`. -É melhor evitar palavras-chave reservadas abreviadas; utilize suas variações com -nome completo (use `ABSOLUTE` ao invés de `ABS`). +É melhor evitar palavras-chave abreviadas; utilize suas variações por extenso +(use `ABSOLUTE` ao invés de `ABS`). -Não utilize palavras-chave de um fornecedor específico de banco de dados -onde for possível utilizar palavras-chave ANSI SQL que tenham a mesma função. +Não utilize palavras-chave de um fornecedor específico de banco de dados. Onde for +possível, utilize palavras-chave reservadas ANSI SQL que tenham a mesma função. Isso ajuda na portabilidade do código. ```sql @@ -173,16 +173,15 @@ SELECT model_num ### Espaços em branco -Para tornar o código mais fácil de ler, é importante que o cumprimento correto -de espaçamento esteja sendo utilizado. Não coloque código ou remova espaços -naturais da linguagem. +Para tornar o código mais fácil de ler, é importante o uso correto do espaçamento. +Não insira código ou remova espaços em linguagem natural. #### Espaços Espaços devem ser utilizados para alinhar o código, de forma que as palavras-chave -terminem sempre no mesmo limite de caracteres. Isso forma um rio tipográfico, -tornando fácil bater olho, visualizar o código e separar as palavras-chave dos -detalhes de implementação. Rios são [ruins na tipografia][rivers], mas úteis aqui. +fiquem sempre no mesmo limite. Isso forma um rio tipográfico, tornando fácil visualizar +o código e separar as palavras-chave dos detalhes de implementação. +Rios são [ruins na tipografia][rivers], mas úteis aqui. ```sql (SELECT f.species_name, @@ -204,15 +203,15 @@ detalhes de implementação. Rios são [ruins na tipografia][rivers], mas úteis GROUP BY b.species_name, b.observation_date) ``` -Note que o `SELECT`, `FROM`, etc. estão todos a direita, alinhados, enquanto -os nomes das colunas em si e os detalhes específicos de implementação estão -alinhados à esquerda. +Note que o `SELECT`, `FROM`, etc. estão todos alinhados à direita, enquanto +os nomes das colunas em si e os detalhes de implementação estão alinhados à +esquerda. Sempre inclua espaços: -* antes de depois do símbolo igual (`=`) +* antes e depois do símbolo igual (`=`) * depois de vírgulas (`,`) -* ao redor de apóstrofes (`'`) caso não estejam entre parênteses, com uma vírgula +* ao redor de apóstrofes (`'`) caso não estejam entre parênteses ou com uma vírgula ou ponto e vírgula. ```sql @@ -227,15 +226,15 @@ SELECT a.title, a.release_date, a.recording_date Sempre inclua novas linhas/espaço vertical: * antes de `AND` ou `OR` -* depois de vírgulas, separando as queries para uma leitura mais fácil +* depois de vírgulas, separando as queries para facilitar a leitura * depois de cada definição de palavras-chave * depois de um ponto, quando seperando múltiplas colunas em grupos lógicos * para separar código em seções relacionadas, o que ajuda na legibilidade de grandes pedaços de código. -Manter todas as palavras-chave alinhadas ao lado direito e os valores alinhados -ao lado esquerdo, cria uma lacuna no meio da query. Isso torna muito mais fácil -e rápido a análise da definição da query. +Manter todas as palavras-chave alinhadas à direita e os valores alinhados +à esqueda cria uma lacuna no meio da query. Isso torna a análise da definição +da query mais fácil e rápida. ```sql INSERT INTO albums (title, release_date, recording_date) @@ -259,13 +258,13 @@ SELECT a.title, ### Indentação -Para garantir que o SQL fique legível, é importante que padrões de indentação +Para garantir que o SQL seja legível, é importante que padrões de indentação sejam seguidos. #### Joins -Joins devem ser indentados do outro lado do rio e agrupados com uma nova linha -quando necessário. +Joins devem ser indentados do outro lado do rio tipográfico e agrupados +com uma nova linha quando necessário. ```sql SELECT r.last_name @@ -281,10 +280,10 @@ SELECT r.last_name #### Subqueries -Subqueries também devem ser alinhadas do lado direito do rio e então seguir o -mesmo estilo de qualquer outra query. As vezes faz sentido ter o parêntese de -fechamento em uma nova linha na mesma posição que o parêntese de abertura foi -definido—isso é especialmente importante onde você tem subqueries aninhadas. +Subqueries também devem ser alinhadas à direita do rio e seguir o mesmo estilo +de qualquer outra query. As vezes faz sentido ter o parêntese de fechamento em +uma nova linha na mesma posição que o parêntese de abertura foi definido—isso é +especialmente importante onde você tem subqueries aninhadas. ```sql SELECT r.last_name, @@ -307,9 +306,9 @@ SELECT r.last_name, * Onde um valor precisa ser interpretado antes de ser retornado pelo banco de dados, use a expressão `CASE`. Cláusulas `CASE` podem ser aninhadas para formar estruturas lógicas mais complexas. -* Evite o uso de cláusulas `UNION` e tabelas temporários quando possível. Se - o schema pode ser otimizado, removendo a dependência desses recursos, então - é provável que essa otimização deve ser feita. +* Evite o uso de cláusulas `UNION` e tabelas temporárias quando possível. Se + o schema pode ser otimizado removendo a dependência desses recursos, é melhor + otimizar. ```sql SELECT CASE postcode @@ -324,19 +323,19 @@ SELECT CASE postcode ## Sintaxe Create -Enquanto declarando informação do schema, é importante manter código legível -por humanos. Para facilitar isso, tenha certeza que as definições das colunas -estão ordenadas e agrupadas onde fizer sentido. +Enquanto declarando informação do schema, é importante manter um código humanamente +legível. Para garantir isso, assegure-se de que as definições das colunas estejam +ordenadas e agrupadas onde fizer sentido. Indente definições de coluna com quatro (4) espaços dentro da definição `CREATE`. ### Escolhendo tipos de dados -* Onde possível, não utilize tipos de dados específicos de certos tipos de banco - de dados—eles não são portáteis e podem não estar disponíveis em versões antigas - do mesmo banco de dados. -* Apenas utilize os tipos `REAL` ou `FLOAT` onde é estritamente necessário para - utilizar pontos flutuantes, do contrário prefira sempre `NUMERIC` e `DECIMAL`. +* Onde possível, não utilize tipos de dados específicos de fornecedores de banco + de dados—esses formatos geralmente não são portáteis e podem estar indisponíveis + em versões antigas do banco de dados do mesmo fornecedor. +* Utilize os tipos `REAL` ou `FLOAT` apenas onde o uso de pontos flutuantes for + estritamente necessário, do contrário prefira sempre `NUMERIC` e `DECIMAL`. Erros de ponto flutuante são um transtorno! ### Especificando valores padrão