Conventions de dénomination PostgreSQL

193

Où puis-je trouver un manuel détaillé sur les conventions de dénomination PostgreSQL? (noms de table vs cas de chameau, séquences, clés primaires, contraintes, index, etc ...)

postgresql naming-conventions

— boj
source

Eh bien, si nous allons un peu plus loin et examinons la convension de dénomination générique, je recommande vivement de vérifier cette réponse: stackoverflow.com/questions/4702728

— ...

Réponses:

254

En ce qui concerne les noms de tables, la casse, etc., la convention la plus courante est:

Mots clés SQL: UPPER CASE
noms (identifiants): lower_case_with_underscores

Par exemple :

UPDATE my_table SET name = 5;

Ce n'est pas écrit dans la pierre, mais le peu sur les identifiants en minuscules est fortement recommandé, IMO. Postgresql traite les identifiants de manière insensible à la casse lorsqu'ils ne sont pas cités (il les plie en fait en minuscules en interne), et à la casse lorsqu'ils sont cités; beaucoup de gens ne sont pas conscients de cette idiosyncrasie. En utilisant toujours des minuscules, vous êtes en sécurité. Quoi qu'il en soit, il est acceptable d'utiliser camelCaseou PascalCase(ou UPPER_CASE), tant que vous êtes cohérent: citez toujours ou jamais les identifiants (et cela inclut la création du schéma!).

Je ne connais pas beaucoup plus de conventions ou de guides de style. Les clés de substitution sont normalement faites à partir d'une séquence (généralement avec la serialmacro), il serait pratique de s'en tenir à cette dénomination pour ces séquences si vous les créez à la main (tablename_colname_seq ).

Voir aussi une discussion ici , ici et (pour SQL général) ici , le tout avec plusieurs liens connexes.

Remarque: Postgresql 10 a introduit des identity colonnes comme un remplacement conforme à SQL pour serial .

— Leonbloy
source

FWIW, la seule idiosyncrasie est que Pg se plie en minuscules, là où le standard SQL dit qu'il doit se plier en majuscules. Les SGBD qui ne parviennent pas à se replier sont les plus étranges non standard.

— Craig Ringer

En tant que nouvel utilisateur de Postgres, c'est assez frustrant. Avoir à choisir entre taper des guillemets tout le temps ou utiliser une vilaine convention de dénomination est nul. Ça craint le cul.

— d512 le

@ user1334007 La convention n'est pas laide - et lisez le commentaire de Craig ci-dessus. Et il n'est pas nécessaire de citer si vous n'avez pas cité lorsque vous avez créé les tables (c'est-à-dire si vous êtes cohérent).

— leonbloy

@leonbloy, si vous ne citez pas lorsque vous créez la table, Postgres réduira en minuscules les noms de vos tables et de vos champs. Vous pouvez utiliser la casse camel lorsque vous écrivez vos requêtes, mais votre résultat s'affichera en minuscules, ce qui est difficile à lire lorsque les champs se composent de plusieurs mots (lastupdateddate). Si vous voulez que vos noms de colonnes soient lisibles dans les résultats de la requête, vous devez tout citer ou utiliser le cas du serpent, ce qui, à mon avis, est moche. Ce serait beaucoup mieux si Postgres laissait vos noms seuls et ne vous demandait pas de fournir des devis.

— d512

Je déteste les mots-clés en majuscules, je déteste juste, convention ou non. Il n'y a pas de casse en ce qui concerne les mots clés. Je préfère tous les minuscules. Oui, je sais que c'est une simple préférence, mais c'est aussi un simple commentaire. ;-)

— Craig

Il n'y a pas vraiment de manuel formel, car il n'y a pas de style ou de norme unique.

Tant que vous comprenez les règles de dénomination des identifiants, vous pouvez utiliser ce que vous voulez.

En pratique, je trouve cela plus facile à utiliser lower_case_underscore_separated_identifierscar il ne leur est pas nécessaire "Double Quote"partout de préserver le boîtier, les espaces, etc.

Si vous vouliez nommer vos tables et "@MyAṕṕ! ""betty"" Shard$42"vos fonctions, vous seriez libre de le faire, même si ce serait pénible de taper partout.

Les principales choses à comprendre sont:

À moins d'être entre guillemets, les identificateurs sont mis en minuscules, donc MyTable, MYTABLEet mytablesont tous la même chose, mais "MYTABLE"et "MyTable"sont différents;
Sauf indication contraire:

Les identificateurs SQL et les mots clés doivent commencer par une lettre (az, mais aussi des lettres avec des signes diacritiques et des lettres non latines) ou un trait de soulignement (_). Les caractères suivants d'un identificateur ou d'un mot clé peuvent être des lettres, des traits de soulignement, des chiffres (0-9) ou des signes dollar ($).
Vous devez double-citer les mots-clés si vous souhaitez les utiliser comme identifiants.

En pratique, je vous recommande vivement de ne pas utiliser de mots clés comme identifiants. Évitez au moins les mots réservés. Ce "with"n'est pas parce que vous pouvez nommer une table que vous devriez le faire.

— Craig Ringer
source

Merci d'avoir créé un lien vers la documentation sur les règles de dénomination des identifiants . J'ai eu du mal à trouver ce sujet particulier.

— Basil Bourque

"Je trouve que c'est plus facile à utiliser lower_case_underscore_separated_identifiers" ... récemment, j'ai entendu cela décrit comme "cas de serpent"

— bvj