Convenciones oficiales de capitalización de PostgreSQL [cerrado]

¿Existe una convención oficial de PostreSQL con respecto a la capitalización en DB, Tabla y nombres de campo?

Los ejemplos en el sitio oficial sugieren una _separación de minúsculas y palabras, y me pregunto si esta política es oficial.

CREATE TABLE films (
    code        char(5) CONSTRAINT firstkey PRIMARY KEY,
    title       varchar(40) NOT NULL,
    did         integer NOT NULL,
    date_prod   date,
    kind        varchar(10),
    len         interval hour to minute
);

Básicamente voy a reflejar los comentarios de Verace y decir esto, haciéndolo semioficial:

No hay una mejor práctica que cubra todas las circunstancias. Lo que sigue hace las siguientes suposiciones (y qué hacer si no ha hecho esto):

• Ya ha discutido esto con su equipo (las personas que trabajan solas a menudo solo tienen que decidirse)
• Ya no hay una definición de estilo formal para SQL en su equipo (de lo contrario, no nos preguntará)
• No existe una definición de estilo formalizada para ningún código (siga las mismas convenciones básicas ya establecidas para otros idiomas y formalice un estilo)

Entonces, el resto de esto es algo obstinado pero basado en la experiencia

1. Cuando se trata de nombres de tablas
   1. Debería elegir nombres de entidades singulares (esto facilita la documentación)
   2. Deberías usar Pascal Case aquí
2. Cuando se trata de nombres de campo
   1. Use camelCase en sus nombres de campo
   2. Use nombres singulares cortos a menos que la definición definitivamente tenga sentido como un plural (casi nunca lo hace)
3. Cuando se trata de su propia función o nombres de procedimientos almacenados
   1. Usar subrayado_separación
   2. Utilice la denominación de campo para la parametrización.
4. Cuando se trata de funciones de base de datos incorporadas o nombres de idiomas (por ejemplo, SELECCIONAR)
   1. A menos que haya un requisito para que se capitalice de cierta manera, use TODAS LAS MAYÚSCULAS
   2. Conozca las API de su idioma para saber qué es razonable o necesario
5. Cuando se trata de espaciado
   1. Mucha gente usa la alineación de columnas para palabras clave y la sangría para cosas que no son palabras clave
   2. Mucha gente usa comas al comienzo de la fila cuando los campos están separados en cada línea (esto hace que sea más fácil comentar un campo específico de una lista de selección)
   3. Nunca use espacios como parte de los nombres de las cosas, ni siquiera para los encabezados de valor de retorno.
6. Cuando se trata de puntuación
   1. Paréntesis - UTILÍCELOS. Están libres. Lo prometo.
   2. Punto y coma - UTILÍCELOS. No te van a romper. Te obligan a pensar en tu código. Y son buena higiene.
   3. Devoluciones de carro - Una vez más, son gratis ;-) Y hacen que su código sea legible.

También debe reconocer que, aunque estoy tratando de ayudarlo a aplicar una guía de estilo genérica, la comunidad de Postgres generalmente no usa camelCase o PascalCase, sino que usa underscore_separation. Lo realmente importante es asegurarse de establecer y utilizar un estilo específico en todas partes para ser coherente .

Un Google rápido revelará muchos sitios que indican las mejores prácticas. Solo diría dos cosas: NUNCA use espacios "My Table Name" (el portado se vuelve imposible debido a diferentes mecanismos de escape; lo mismo ocurre con cualquier carácter no alfanumérico). Con este tipo de mecanismos, normalmente también debe respetar el caso. Hay suficientes letras y palabras en el idioma inglés (o el suyo) y las longitudes de los identificadores son lo suficientemente largas (no conozco ningún sistema que tenga identifier_length <32, PostgreSQL es 64). Y nunca use palabras clave SQL (que varían según RDBMS) que harán lo mismo.

Declaraciones como

SELECT "Field" FROM "Table";

puede ser valido! Lo absolutamente crítico es tener una convención clara y relativamente simple y luego cumplirla. Las personas tienen diferentes opiniones, como descubrirá: lea sobre el tema y elija lo que le parezca "correcto". Vea estos sitios 1 , 2 , 3 , 4 , 5 , ... (hay muchos más).