Existe um bom motivo para usar maiúsculas para palavras-chave SQL? [fechadas]

O padrão parece estar em maiúsculas, mas existe realmente algum motivo para usar maiúsculas para palavras-chave? Comecei a usar maiúsculas porque estava apenas tentando corresponder ao que o SQL Server me dava sempre que tentava criar algo, como um novo procedimento armazenado. Mas então, eu me senti péssima pelo meu dedo (quinto), que sempre precisa pressionar o Shiftbotão, então parei de usar letras maiúsculas. Alguma razão para eu voltar para maiúsculas?

Edit : Obrigado pelas respostas pessoal. Eu ainda não estava programando nos dias em que o COBOL era rei, então não estava ciente disso. Eu vou ficar com letras minúsculas a partir de agora.

É apenas uma questão de estilo, provavelmente originada nos dias em que os editores não faziam a coloração do código.

Eu costumava preferir todas as letras maiúsculas, mas agora estou me inclinando para todas as letras minúsculas.

Pessoalmente, eu não gosto do meu SQL gritando comigo. Lembra-me de básico ou de COBOL.

Por isso, prefiro minha letra minúscula T-SQL com nomes de objetos de banco de dados MixedCase.

É muito mais fácil ler, e literais e comentários se destacam.

SQL está velho. O CASO SUPERIOR ESTÁ GRITANDO. Parece estranho e talvez feio.

Embora seja indiscutivelmente verdade, nenhum deles aborda os motivos especiais da linguagem SQL para que palavras-chave em maiúsculas sejam uma boa convenção.

Ao contrário de muitas linguagens mais recentes, o SQL possui um grande número de palavras - chave e depende da capacidade do leitor de distinguir palavras-chave versus identificadores para analisar mentalmente a sintaxe.

A resposta direta à sua pergunta, então, é mais uma resposta para "por que o leitor de código SQL se beneficia tanto das palavras-chave maiúsculas, quando isso não é verdade para a maioria das linguagens modernas?":

• Confiar em manter as palavras - chave na cabeça é razoável para muitas linguagens modernas, mas irracional para SQL ; possui muitas palavras-chave e muitas variantes.

• Confiar em sinais de pontuação é razoável para a maioria das linguagens modernas, mas irracional para SQL ; possui muito pouco, dependendo da ordem precisa das palavras-chave para indicar a sintaxe.

• Contar com marcadores automáticos para distinguir palavras-chave é razoável para linguagens modernas em casos comuns, mas ignora a realidade do que os marcadores podem obter para o SQL . A maioria não cobre todas as palavras-chave de todas as variantes do SQL e, independentemente disso, o SQL é frequentemente e rotineiramente lido em contextos em que um marcador não ajuda.

Esses são alguns dos motivos, específicos para SQL, de que o leitor de código SQL é melhor atendido ao padronizar letras maiúsculas para palavras-chave e usar apenas letras não maiúsculas (ou seja, minúsculas ou mistas) para identificadores.

Realçar às vezes pode ajudar. Mas somente se o marcador souber que você possui SQL; e muitas vezes temos o SQL em um contexto em que o editor / formatador não pode razoavelmente saber que está lidando com o SQL. Os exemplos incluem consultas em linha, documentação do programador e seqüências de texto no código de outro idioma. O mesmo não é verdade em qualquer lugar próximo com tanta freqüência para linguagens como Python ou C ++; sim, o código deles às vezes aparece nesses locais, mas não é rotineiramente feito da maneira que é com o código SQL.

Além disso, o leitor normalmente usa um marcador que conhece apenas um subconjunto das palavras-chave que sua implementação SQL específica usa. Muitas das palavras-chave menos comuns não serão destacadas, exceto por uma que conhece intimamente sua variante SQL. Portanto, o leitor, mesmo que esteja usando um marcador, ainda precisa de uma maneira mais direta de distinguir palavras-chave em qualquer instrução SQL moderadamente complexa.

Assim, o leitor frequentemente - e o escritor não pode saber antecipadamente quando isso será - precisar de assistência do conteúdo da própria instrução SQL, para saber o que o escritor pretende como uma palavra-chave e o que pretende como um identificador. Portanto, o próprio conteúdo SQL precisa distinguir palavras-chave para o leitor , e usar palavras-chave em maiúsculas é a maneira convencional e útil de fazer isso.

Os exemplos de Gordon Bell não estão exatamente corretos; geralmente, apenas as palavras-chave são destacadas, não a consulta inteira. Seu segundo exemplo seria assim:

SELECT name, id, xtype, uid, info, status, 
base_schema_ver, replinfo, parent_obj, crdate, 
ftcatid, schema_ver, stats_schema_ver, type, 
userstat, sysstat, indexdel, refdate, version, 
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

Acho isso muito mais fácil de ler, pois as palavras-chave se destacam mais. Mesmo com o destaque da sintaxe, acho o exemplo sem capitalização muito mais difícil de ler.

Na minha empresa, vamos um pouco mais longe com a nossa formatação SQL.

SELECT      name, id, xtype, uid, info, status, 
            base_schema_ver, replinfo, parent_obj, crdate, 
            ftcatid, schema_ver, stats_schema_ver, type, 
            userstat, sysstat, indexdel, refdate, version, 
            deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
LEFT JOIN systhingies ON
    sysobjects.col1=systhingies.col2
WHERE category = 0
    AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

Houve um tempo em que a maioria das pessoas não tinha a possibilidade de codificar qualquer coisa além das letras maiúsculas de maiúsculas, porque a codificação relevante (ASCII) ainda não foi inventada. Apenas seis bits estavam disponíveis . QUANDO O SQL É MAIS RECENTE, AS LETRAS DE CASO MAIS BAIXAS NÃO FORAM PRÁTICAS COMUM NA PROGRAMAÇÃO AINDA.

OBSERVE QUE ALGUMAS PESSOAS RECLAMAM QUE A BASE DE DADOS TERÁ UM SENTIDO DE URGÊNCIA E EXECUTARÁ AS SUAS QUESTÕES MAIS RAPIDAMENTE.

Menos de 10% das letras no texto que lemos são maiúsculas. Portanto, nossos cérebros estão mais interessados ​​em reconhecer letras minúsculas do que letras maiúsculas. Estudos mostraram que demora mais para ler o texto em maiúsculas. Aqui está apenas um exemplo:

http://www.guardian.co.uk/media/mind-your-language/2010/oct/04/new-york-street-signs-capitals

Acho que o exemplo acima enfatiza que, mesmo quando você está falando de apenas uma ou duas palavras, isso faz a diferença.

É porque o SQL é uma linguagem tão antiga ( 1974 ) que, quando foi concebida, a maioria dos teclados não tinha letras minúsculas! A documentação do idioma simplesmente refletia a tecnologia da época.

Pesquisas comprovaram que TODOS OS CAPS são mais difíceis de ler, tanto que a Administração Federal de Rodovias dos EUA determinou o uso de sinais em maiúsculas e minúsculas em seu Manual sobre dispositivos uniformes de controle de tráfego, que declara:

As letras para nomes de lugares, ruas e rodovias nas placas de guia convencionais devem ser uma combinação de letras minúsculas com letras maiúsculas iniciais.

O New York Post também publicou:

Estudos mostraram que é mais difícil ler sinais de letras maiúsculas, e os milissegundos extras gastos olhando para longe da estrada demonstraram aumentar a probabilidade de acidentes, principalmente entre os motoristas mais velhos.

Não há boas razões para usar letras maiúsculas e boas razões para não usar.

Pessoalmente, detesto usar maiúsculas para palavras-chave SQL. Acho mais difícil ler e absurdo hoje em dia.

A linguagem SQL é definida como sem distinção entre maiúsculas e minúsculas. Tire o dedo dessa tecla shift!

Letras maiúsculas podem fornecer um ganho na visibilidade das palavras-chave, mas você pode compensar com o realce e o recuo do código.
Usamos letras minúsculas porque o editor de consultas e outras ferramentas fazem maravilhas na edição do código t-sql e não vemos necessidade de torturar o dedo mindinho.

Macaco vê, macaco faz por mim. Correspondência de padrões - se eu fizer da maneira que vi, a estrutura das cláusulas se alinha mentalmente mais facilmente.

Letras maiúsculas são menos legíveis. O contorno de todas as palavras tem o formato de caixas; não há descendentes ou ascendentes. FTW em minúsculas!

Acho mais legível. O mesmo para ter uma nova linha para o início de cada cláusula e recuar entre cláusulas.

Tente um produto de formatação (eu uso o SQL Prompt / SQL Refactor do Red Gate). Você pode definir como deseja que a capitalização funcione e seu código sempre será sempre formatado. Descanse seu mindinho e deixe o computador fazer o trabalho por você.

Um dos motivos para continuar usando maiúsculas é quando você (ou outra pessoa) está visualizando o código em algo como o bloco de notas, facilitando a leitura. ou seja, você pode diferenciar facilmente entre as "palavras-chave" e os nomes das tabelas, SP's, udf's etc.

À excepção da conformidade por causa das conformidades, não. Embora seja um tópico muito subjetivo, prefiro usar maiúsculas e minúsculas para todo o SQL. O SQL é muito mais fácil de ler e nada se perde nos IDEs modernos, onde as palavras-chave são todas codificadas por cores.

O intellisense / autocompletar no Microsoft SQL Server Management Studio permite maiúsculas ou minúsculas para palavras reservadas, mas as funções em maiúsculas chamam como MAX (), SUM ().

Mesmo assim, o analisador ainda permite que versões em minúsculas de max () e sum () sejam processadas.

Isso implica uma ambivalência com relação à natureza da execução e, portanto, é simplesmente uma questão de preferência pessoal.

Não gosto de nada escrito em letras maiúsculas (e odeio digitar letras maiúsculas ainda mais), mas não consegui me convencer a ir contra a comunidade. Como de costume, o Vim e seus pacotes associados são a solução para muitos problemas:

http://www.vim.org/scripts/script.php?script_id=305

Basta digitar como normal e as palavras-chave serão colocadas em maiúsculas automaticamente enquanto você digita. Eu não usei todos os encantamentos obscuros do SQL, mas ainda não me falhou.

Eu chamo a maior parte do meu código mySQL a partir do PHP e faço toda a minha edição do PHP no vim (ou suponho, neste caso, VIM ;-). Agora tenho certeza de que existem plugins para destacar o código mySQL no PHP, mas não o encontrei e não tenho tempo para procurá-lo. Portanto, prefiro ter tudo em maiúsculas. Eu acho isso:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
CREATE TABLE IF NOT EXISTS HISTORY
(
   ID INT NOT NULL AUTO_INCREMENT,
   INSERTDATE TIMESTAMP DEFAULT NOW(),
   ALTERDATE TIMESTAMP(8) DEFAULT NOW(),
   DELETEDATE TIMESTAMP(8),
   ALTERCOUNT INT DEFAULT 0,
   SELECTCOUNT INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB
";

mysqlQuery( $query, $con );

Ajuda-me a distinguir entre PHP e SQL muito melhor do que isso:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
create table if not exists history
(
   id int not null auto_increment,
   insertdate timestamp default now(),
   alterdate timestamp(8) default now(),
   deletedate timestamp(8),
   altercount int default 0,
   selectcount int default 0,

   primary key(id),
)engine=InnoDB
";

mysqlQuery( $query, $con );

Além disso, por alguma razão, eu odeio misturar allcaps com camel case, assim:

CREATE TABLE IF NOT EXISTS history
(
   ID INT NOT NULL AUTO_INCREMENT,
   insertDate TIMESTAMP DEFAULT NOW(),
   alterDate TIMESTAMP(8) DEFAULT NOW(),
   deleteDate TIMESTAMP(8),
   alterCount INT DEFAULT 0,
   selectCount INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB

Isso IDme irrita. Em vez disso, deveria ser id? ou iD?