upper primera minúsculas minusculas mayúsculas mayusculas mayuscula letra estandares entre ejemplo distingue diferenciar datos buscar sql coding-style capitalization

primera - sql distingue entre mayúsculas y minúsculas



¿Hay una buena razón para usar mayúsculas para palabras clave SQL? (17)

El valor predeterminado parece ser mayúscula, pero ¿hay realmente alguna razón para usar mayúsculas para las palabras clave? Empecé a usar mayúsculas porque solo estaba tratando de hacer coincidir lo que SQL Server me da cada vez que intenté crear algo, como un nuevo procedimiento almacenado. Pero entonces, me siento mal por el dedo de mi bebé (5º) que siempre tiene que mantener presionado el botón Shift, así que dejé de usar la mayúscula. ¿Alguna razón por la que debería volver a mayúsculas?

Editar: Gracias por las respuestas chicos. No estaba programando aún en los días en que COBOL era rey, así que no estaba al tanto de esto. Me quedaré con minúsculas a partir de ahora.


¡Es porque SQL es un lenguaje tan antiguo ( 1974 ) que cuando se concibió, la mayoría de los teclados no tenían letras minúsculas! La documentación del lenguaje simplemente reflejaba la tecnología del momento.

No hay una buena razón para usar letras mayúsculas. Yo personalmente aborrezco el uso de mayúsculas para palabras clave SQL. Es más difícil de leer y es ridículo en este día y edad e innecesario; el lenguaje SQL se define para que no distinga entre mayúsculas y minúsculas.


Aparte de la conformidad para el bien de las conformidades, no. Aunque es un tema muy subjetivo, prefiero usar mayúsculas y minúsculas para todos los SQL. El SQL es mucho más fácil de leer y no se pierde nada en los IDEs modernos donde las palabras clave están codificadas por colores de todos modos.


El intellisense / autocompletado en Microsoft SQL Server Management Studio permite mayúsculas y minúsculas para las palabras reservadas, pero los casos superiores funcionan como MAX (), SUM ().

Aun así, el analizador aún permite versiones en minúsculas de max () y sum () para ser procesadas.

Esto implica una ambivalencia con respecto a la naturaleza de la ejecución, y por lo tanto es simplemente una cuestión de preferencia personal.


Es solo una cuestión de estilo, probablemente originada en los días en que los editores no aplicaban el código coloreado.

Solía ​​preferir todas las mayúsculas, pero ahora me estoy inclinando hacia todas las inferiores.


HUBO UN TIEMPO CUANDO LA MAYORÍA DE LAS PERSONAS NO TENÍA LA POSIBILIDAD DE CODIFICAR CUALQUIER COSA MÁS ALLÁ DE LAS CARTAS DE MAYÚSCULAS PORQUE LA CODIFICACIÓN PERTINENTE (ASCII) AUN NO SE HA INVENTADO. SOLO SEIS BITS ESTABAN DISPONIBLES . MIENTRAS QUE SQL ES MÁS RECIENTE, LAS CARTAS DE CASO INFERIOR NO ERAN PRÁCTICAS COMUNES EN LA PROGRAMACIÓN TODAVÍA.

TEN EN CUENTA QUE ALGUNAS PERSONAS RECLAMAN QUE LA BASE DE DATOS OBTENDRÁ UN SENTIDO DE URGENCIA Y FUNCIONARÁ MÁS RÁPIDAMENTE.


La mayúscula es menos legible. El contorno de todas las palabras tiene forma de recuadro; no hay descendientes o ascendentes ¡FTW en minúsculas!


La mayúscula puede proporcionar una ganancia en la visibilidad de las palabras clave, pero puede compensar con el resaltado y la sangría del código.
Usamos minúsculas porque el editor de consultas y otras herramientas hacen maravillas al editar el código t-sql, y no vemos la necesidad de torturar el dedo meñique.


Llamo a la mayoría de mi código mySQL desde PHP, y hago toda mi edición de PHP dentro de vim (o supongo que en este caso, VIM ;-). Ahora estoy seguro de que hay complementos para resaltar el código mySQL dentro de PHP, pero no lo he encontrado, y no tengo tiempo para ir a buscarlo. Por lo tanto, prefiero tener todo en mayúsculas. Encuentro esto

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 );

Me ayuda a distinguir entre PHP y SQL mucho mejor que esto:

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 );

Además, por alguna razón, odio mezclar allcaps con estuche de camello, así:

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

Esa ID me molesta. ¿Debería ser id ? o iD ?


Lo encuentro más legible Lo mismo para tener una nueva línea para el comienzo de cada cláusula y sangría entre las cláusulas.


Los ejemplos de Gordon Bell no son exactamente correctos; en general, solo se resaltan las palabras clave, no toda la consulta. Su segundo ejemplo se vería así:

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

Encuentro esto mucho más fácil de leer, ya que las palabras clave se destacan más. Incluso con el resaltado de sintaxis, encuentro que el ejemplo no capitalizado es mucho más difícil de leer.

En mi empresa, vamos un poco más lejos con nuestro formato 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



Mono, mira, el mono lo hace por mí. Coincidencia de patrones: si lo hago como lo he visto, la estructura de las cláusulas se alinea mentalmente más fácilmente.


No me gusta nada escrito en mayúsculas (y odio escribir a tope todas las tapas aún más), pero no pude convencerme a mí mismo de ir en contra de la comunidad. Como de costumbre, Vim y sus paquetes asociados son la solución a muchos problemas:

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

Simplemente escriba como de costumbre y las palabras clave se capitalizarán automáticamente a medida que escribe. No he usado todos los encantamientos de SQL oscuros, pero todavía no me ha fallado.


PERSONALMENTE, NO ME GUSTA MI MALDICIÓN DE SQL. ME RECUERDA DE BASIC O COBOL.

Por lo tanto, prefiero mi minúscula T-SQL con nombres de objetos de base de datos MixedCase.

Es mucho más fácil de leer, y los literales y comentarios se destacan.


Pruebe un producto de formateo (utilizo SQL Prompt / SQL Refactor de Red Gate). Puede configurar cómo quiere que funcione el uso de mayúsculas y minúsculas, y su código siempre tendrá un formato uniforme. Descansa el dedo meñique y deja que la computadora haga el trabajo por ti.


SQL ES VIEJO. EL CASO SUPERIOR ESTÁ GRITANDO. PARECE EXTRAÑO Y QUIZÁS AGRADABLE.

Aunque podría decirse que es cierto, ninguno de ellos aborda las razones especiales para el lenguaje SQL por qué las palabras clave en mayúsculas son una buena convención.

A diferencia de muchos lenguajes nuevos, SQL tiene una gran cantidad de palabras clave y se basa en la capacidad del lector para distinguir palabras clave frente a identificadores con el fin de analizar mentalmente la sintaxis.

La respuesta directa a su pregunta, entonces, es más una respuesta a "¿por qué el lector del código SQL se beneficia tanto de las palabras clave en mayúsculas, cuando eso no es tan cierto para la mayoría de los lenguajes modernos?":

  • Confiar en mantener las palabras clave en la cabeza es razonable para muchos lenguajes modernos, pero irrazonable para SQL ; tiene demasiadas palabras clave y demasiadas variantes.

  • Confiar en las señales de puntuación es razonable para la mayoría de los lenguajes modernos, pero irrazonable para SQL ; tiene muy pocos, en cambio, depende del orden preciso de las palabras clave para indicar la sintaxis.

  • Confiar en marcadores automáticos para distinguir palabras clave es razonable para los idiomas modernos en casos habituales, pero ignora la realidad de lo que los resaltadores pueden lograr para SQL . La mayoría no cubre todas las palabras clave de todas las variantes de SQL, y sin tener en cuenta, SQL se lee con frecuencia y de forma rutinaria en contextos en los que un resaltador no ayuda.

Estas son algunas de las razones, específicas de SQL, para que el lector del código SQL se beneficie al estandarizar en mayúsculas las palabras clave , y solo usar el caso no superior (es decir, más bajo o mixto) para los identificadores.

Resaltar puede a veces ayudar. Pero solo si el resaltador sabe que tienes SQL; y muy a menudo tenemos SQL en un contexto donde el editor / formateador no puede saber razonablemente que se trata de SQL. Los ejemplos incluyen consultas en línea, documentación del programador y cadenas de texto dentro del código de otro idioma. Lo mismo no es cierto en ningún lugar tan a menudo para idiomas como Python o C ++; sí, su código a veces aparece en esos lugares, pero no se hace rutinariamente de la forma en que lo hace con el código SQL.

Además, el lector utilizará comúnmente un resaltador que solo conoce un subconjunto de las palabras clave que utiliza su implementación específica de SQL. Muchas de las palabras clave menos comunes no se resaltarán, excepto una que conozca su variante de SQL de manera íntima. Por lo tanto, el lector, incluso si usa un resaltador, aún necesita una manera más directa de distinguir palabras clave en cualquier declaración SQL moderadamente compleja.

Por lo tanto, el lector frecuentemente -y el escritor no puede saber con anticipación cuándo será eso- necesita ayuda del contenido de la declaración SQL en sí misma, para saber qué pretende el escritor como palabra clave y qué se pretende como identificador. Por lo tanto, el contenido SQL en sí necesita distinguir palabras clave para el lector , y el uso de palabras clave en mayúsculas es la manera convencional y útil de hacerlo.


Una de las razones para continuar usando mayúsculas es cuando usted (u otra persona) está viendo el código en algo parecido a un bloc de notas, lo que hace que sea más fácil de leer. es decir, puede diferenciar fácilmente entre las "palabras clave" y los nombres de tabla, SP, udf, etc.