Conventions officielles de capitalisation PostgreSQL [fermé]

14

Existe-t-il une convention PostreSQL officielle concernant la capitalisation dans les noms de base de données, de table et de champ?

Les exemples sur le site officiel suggèrent une _séparation en minuscules et en mots, et je me demande si cette politique est officielle.

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
);
Adam Matan
la source
1
Consultez également cette partie de la documentation, sur les identifiants
ypercubeᵀᴹ

Réponses:

20

Je vais essentiellement refléter les commentaires de Verace et le dire, le rendant semi-officiel:

Il n'y a pas de meilleure pratique qui couvre toutes les circonstances. Ce qui suit fait les hypothèses suivantes (et que faire si vous ne l'avez pas fait):

  • Vous en avez déjà discuté avec votre équipe (les personnes travaillant seules doivent souvent se décider)
  • Il n'y a pas de définition de style formalisée pour SQL déjà dans votre équipe (sinon vous ne nous le demanderiez pas)
  • Il n'y a pas de définition de style formalisée pour aucun code (suivez les mêmes conventions de base déjà établies pour d'autres langues et formalisez un style)

Donc, le reste est quelque peu d'opinion mais basé sur l'expérience

  1. En ce qui concerne les noms de table
    1. Vous devriez opter pour des noms d'entités singuliers (cela facilite la documentation)
    2. Vous devez utiliser Pascal Case ici
  2. En ce qui concerne les noms de champs
    1. Utilisez camelCase sur les noms de vos champs
    2. Utilisez des noms courts au singulier à moins que la définition ne prenne définitivement un sens au pluriel (elle ne le fait presque jamais)
  3. En ce qui concerne vos propres noms de fonction ou de procédure stockée
    1. Utiliser underscore_separation
    2. Utiliser la dénomination des champs pour le paramétrage
  4. En ce qui concerne les fonctions de base de données intégrées ou les noms de langage (par exemple SELECT)
    1. À moins qu'il ne soit nécessaire de le capitaliser d'une certaine manière, utilisez TOUS LES MAJUSCULES
    2. Connaître les API de votre langue pour savoir ce qui est raisonnable ou requis
  5. En matière d'espacement
    1. Beaucoup de gens utilisent l'alignement des colonnes pour les mots clés et l'indentation pour les choses qui ne sont pas des mots clés
    2. Beaucoup de gens utilisent des virgules au début de la ligne lorsque les champs sont séparés sur chaque ligne (cela facilite la mise en commentaire d'un champ spécifique d'une liste de sélection)
    3. N'utilisez jamais d'espaces dans le nom des choses, pas même pour les en-têtes de valeur de retour.
  6. En matière de ponctuation
    1. Parenthèses - UTILISEZ-LES. Ils sont GRATUITS. Je promets.
    2. Point-virgule - UTILISEZ-LES. Ils ne vont pas te briser. Ils vous obligent à réfléchir à votre code. Et c'est une bonne hygiène.
    3. Retours chariot - Encore une fois, ils sont gratuits ;-) Et rendez votre code lisible.

Vous devez également reconnaître que pendant que j'essaie de vous aider à appliquer un guide de style générique, la communauté de Postgres n'utilise généralement pas camelCase ou PascalCase mais utilise à la place underscore_separation. Le plus important est de s'assurer que vous établissez et utilisez un style spécifique partout pour être cohérent .

jcolebrand
la source
3
+1 pour "Le plus important est de s'assurer que vous établissez et utilisez un style spécifique partout pour être cohérent." La cohérence est la clé. Sans cela, vous devez penser à des choses auxquelles vous ne devriez jamais penser.
Max Vernon
4
Eh bien, camelCase et PascalCase dans PostgreSQL sont un peu douloureux. Vous devez les citer si vous voulez vraiment avoir des noms comme ça, sinon le système les met en minuscules en silence (j'ai presque écrit décapitaliser, quelles que soient les associations qu'il peut susciter).
dezso
Qu'en est-il des noms de base de données? Dois - je utiliser database_name, database-name, DatabaseName, databaseName, etc.?
ma11hew28
1
Cette réponse concerne-t-elle réellement PostgreSQL? Si vous donnez des conseils pour utiliser PascalCase pour les noms de table dans une réponse spécifique à PG, je pense que vous devriez mentionner (a) comment gérer le fait que la plupart des exemples utilisent des mots clés en minuscules et (b) si vous devez citer des noms de table ou laisser PG les plie en minuscules.
AndreKR
@AndreKR voici la chose: je m'attends à ce que les développeurs de logiciels soient des adultes, sachent lire la documentation et discutent avec leur équipe de la façon d'écrire du code de manière cohérente. Cette réponse est un wiki communautaire, ce qui signifie que tout le monde est le bienvenu pour le modifier et l'améliorer. Je ne peux pas dire exactement "c'est la seule façon" et ce n'est pas parce que certaines personnes donnent des exemples en minuscules que c'est la seule façon de vivre. Vous devez trouver votre propre chemin, qui était l'esprit de cette réponse. N'hésitez pas à modifier cette réponse de la communauté pour l'améliorer. Merci!
jcolebrand
4

Un rapide Google révélera de nombreux sites qui indiquent les meilleures pratiques. Je dirais seulement deux choses - n'utilisez JAMAIS les espaces "My Table Name" (le portage devient impossible en raison de différents mécanismes d'échappement; il en va de même pour tout caractère non alphanumérique). Avec ces types de mécanismes, vous devez normalement respecter la casse également. Il y a suffisamment de lettres et de mots dans la langue anglaise (ou la vôtre) et la longueur des identifiants est suffisamment longue (je ne connais aucun système ayant identificateur_longueur <32, PostgreSQL est 64). Et n'utilisez jamais de mots clés SQL (qui varient selon le SGBDR) qui feront la même chose.

Des déclarations comme

SELECT "Field" FROM "Table";

peut être valide! L'essentiel, c'est d'avoir une convention claire et relativement simple, puis de s'y tenir. Les gens ont des opinions différentes, comme vous le découvrirez - lisez autour du sujet et choisissez ce qui vous convient. Voir ces sites 1 , 2 , 3 , 4 , 5 , ... (il y en a beaucoup plus).

Vérace
la source
Merci, j'en suis tombé sur beaucoup dans mes propres recherches. Je voulais savoir s'il y avait un guide de style officiel.
Adam Matan
Il y a de nombreux praticiens des deux côtés du débat (singular_table_name / plural_table_name) dont je respecte les opinions sur d'autres domaines. Je suis moi-même un "célibataire" - si vous exploitez une centrale nucléaire, vous pourriez avoir une table appelée catastrophic_meltdown dans laquelle vous ne voulez jamais voir aucun enregistrement! Donnez à vos clés primaires un suffixe _id et faites-les référence à Parent_Table_Name_FK dans les tables enfants - c'est ce que je fais. Après cela, c'est facile! En ce qui concerne les majuscules / sans majuscules, mes scripts SQL ont un cas de chameau (non cité), mes déclarations peuvent ou non.
Vérace