web-dev-qa-db-fra.com

Conventions de dénomination PostgreSQL

Peut-être double poste mais je n'ai trouvé aucune réponse ici.

J'ai vu quelques articles comment nommer mes tables et j'ai compris que (semi-officiellement) il devrait contenir des minuscules, devrait être souligné et singulier (par exemple ma_table)

Ma question s'est posée quand j'ai dû faire ce qui suit. J'ai une application où j'ai utilisateur, plate-forme et user_info, où plate-forme est ce sur quoi l'utilisateur travaille (par exemple MAC, PC, LINUX). Si j'ai besoin de créer une table de jonction entre l'utilisateur et la plate-forme, comment puis-je la nommer pour que la prochaine personne parcourant le schéma comprenne que l'utilisateur et la plate-forme ont une table de jonction nommée user_platform, mais à ne pas confondre quand il voit la table user_info?

BR

postgresqlnaming-convention
2
Pentarex

Dans le cas où le raisonnement derrière les noms en minuscules n'était pas clair, voici pourquoi: Postgres automatiquement et de manière invisible replie les noms. Donc, tous ces noms sont les mêmes:

user_platform

USER_PLATFORM

UsEr_PlAtFoRm

Ils sont tous user_platform en interne. Sauf si vous les mettez entre guillemets:

"UserPlatform" est "UserPlatform". Mais pour utiliser ce champ ou cette table, vous devrez alors mettre le nom entre guillemets partout vous l'utilisez. C'est une douleur totale. Donc, c'est assez standard de voir des noms comme

user_platform

Cela dit, tant que vous n'utilisez pas les guillemets doubles, vous pouvez écrire le nom

User_Platform

si vous le trouvez plus facile à lire.

En ce qui concerne la convention de dénomination, oui, choisissez-en une respectez-la et documentez vos règles. Vous obtenez 64 caractères avec lesquels travailler (par défaut), ce que je n'ai pas trouvé être un problème, sauf parfois pour les noms d'index.

Pour lier des tables, tout ce que vous aimez est bien. Relier les utilisateurs et les plateformes?

user_platform

user_link_platform

ce que tu préfères.

En ce qui concerne l'argument singulier vs pluriel, c'est une question de goût. Certaines personnes s'en soucient. Beaucoup. Les gouttières rougissent du sang des injustes! Je dis fais ce que tu veux. Je fais partie de l'école de création de noms de table, mais surtout parce que c'est une habitude que j'ai prise il y a longtemps.

Ah, une chose à propos des guillemets doubles ... Je les utilise. Nous expédions les données Postgres à un programme de visualisation/d'analyse appelé Domo. Pour cela, il est préférable d'avoir des noms de colonne (attribut) dans MixedCase. Pour cela, je crée des vues avec des alias de colonne "MixedCase" afin que les données soient exportées avec un nom "MixedCase". Il s'agit d'un scénario légèrement exotique, mais vous rencontrerez peut-être un jour quelque chose de similaire. Normalement, je changerais les tables côté client, mais les vues étaient la solution la plus simple.

Astuce bonus! Si vous ne l'avez pas déjà découvert, les champs de texte Postgres sont sensibles à la casse. Si vous n'aimez pas ça, vous pouvez:

  • Écrivez vos requêtes pour traiter les données à l'aveuglette. Chaque. Célibataire. Requete.
  • Utilisez l'extension citext standard. (Texte insensible à la casse.)
  • Attendez que PG12 soit livré avec des classements insensibles à la casse. (Je ne l'ai pas encore essayé.)

J'ai oublié de mentionner ... Postgres a un support exceptionnellement bon pour commenter les éléments du système, y compris les tableaux:

https://www.postgresql.org/docs/current/sql-comment.html

Quelqu'un doit chercher et lire vos commentaires, bien sûr, mais c'est un autre endroit où vous pouvez fournir un contexte. Même si ce contexte n'est rien d'autre qu'un lien vers un wiki que vous maintenez, etc.

2
Morris de Oryx