Bonjour,
 
j'ouvre ce topic pour connaitre les bonnes pratiques et conventions (standardisées ou non) que vous utilisez pour créer vos schémas de DB.
Je pense que c'est important pour éviter des problèmes (surtout quand on est un débutant)
 
Voici les miennes:
 
nom de tables et champs
 
- toujours au singulier:
avant je nommais mes tables au pluriel, car c'était plus logique, mais apparemment, le standard SQL préconise le singulier (donc user au lieu de users).
(Après lectures d'articles, il semblerait que le pluriel pose des problèmes dans certains cas)
 
- noms en anglais
- minuscules
- nom composés: séparés par des undescores

Nom des tables : toujours au singulier, toujours en minuscule
Nom des colonnes : lower camelcase : id_Candiat
Tables filles (relation 1-n)  : nom du parent en préfixe, séparé par un undescore. ex: candidat, candidat_suivi et candidat_suivi_avis par exemple sur 3 niveaux  
Noms composés : collés (exemple : candidat_compterendu)
 
Déclaration des clés étrangères dans le schéma en évitant la suppression en cascade (je préfère le remplacement par NULL). Gestion de la suppression en cascade via triggers (after_delete) pour logger l'opération.
Nom des clés étrangères correspondant à la clé primaire : id_Candidat de la table candidat (clé primaire) et id_Candidat dans candidat_suivi comme clé étrangère
 
En gros pour ma part.

Mes habitudes (qui ne sont pas forcément des conventions) :
 
- Bases en majuscules, tables et colonnes en minuscule (PascalCase, pas d'underscores sauf parfois pour séparer des groupes de noms composés).
- Tables au pluriel, colonnes au singulier. Pk : NomDeLaTableId, FK : NomDeLaTableId.
 
Les tables au pluriel c'est pas systématique, c'est une considération pour le dév : lors de l'utilisation d'un ORM ça permet d'avoir des noms de classes différents entre la DAL et les couches métiers/UI vu que le "s" va disparaitre.  
 
Une autre option c'est d'ajouter à la main un suffixe pour toutes les classes liées à l'ORM (genre "Record" ).
 
Pas d'actions en cascades.

Je fais à peu près comme TotalRecall sauf pour les majuscules/minuscules.
Tables au pluriel. Ex : MeetingRooms
Colonnes en reprenant le nom de la table mais au singulier. Ex : MeetingRoomID, MeetingRoomName...
Pour les clés étrangères, je reprends le nom de la clé primaire d'où provient la clé étrangère.
Pour les relations n-n, j'accole le nom des 2 ou 3 tables concernées.

Dans mon cas :
 
Tables toujours au pluriel.
Colonnes toujours au singulier sauf exception si la colonne contient un array ou un JSON.
Aucune majuscule. J'utilise l'underscore pour séparer les mots
J'utilise le "2" pour les relations. Exemple message2users
 
Mais bon, tout cela est une question d'habitude avant tout. L'essentiel, c'est que celui qui récupère le code comprenne bien de quoi il s'agit.

Bonjour,

pour les tables : en majuscules et noms singuliers, courts. pas d'acronymes.

pour les colonnes :
idem
je mets souvent les 3 premieres lettres du nom de la table puis un 'underscore' en séparateur ( pour une lecture plus facile ) et le nom de colonne toujours en majuscule.

ID toujours en premier ( un ID ça types la table , relation aussi , car des tables n'ont pas toujours un ID pour elles ).
les ID ( clé étrangères ) en fin de table, c'est un reste de cours ( CREATE TABLE .... ).

Je vais vers les majuscules , car :
- c'est core ..  c'est pas du texte pour GUI
- c'est une ressource system/software au moment ou je code.
- et surtout pour éviter de m'emmeler les pinceaux quand c'est la grande heure de la requete de 15 km ... je me trompes moins comme ça.
- lecture + rapide, c'est des repères visuels oui. ( min != caps )
- je rends développement durable les touches Verr Maj et la touche shift.
- moins de swap MIN / maj

PK : primary Key  , c'est comme ID ... pourquoi pas après tout.

djinto, c'est moi ou depuis 3-4j, tu nous fais des réponses très détaillées à tous les topics sur le SQL (voire déterrages comme dans le cas présent) ?  

euh ... si c'est toi , préviens quand même ... je lui dirai tout de suite  
je voulais répondre à toutes cases 'input' disponibles , mais au boulot ils ont grognés. [ //fin joke

pour le déterrage ... je lis pas les dates , c'est autre chose.

Une autre fois, j'ai dit "merci" sur un post qui avait presque 20 ans... ça m'a pas trop gêné.

Bon, en même temps le déterrage sur une cat aussi populaire que celle-ci c'est très relatif, il suffit de descendre rien qu'en bas de la première page pour avoir fait un bond de deux ans en arrière

djinto, il est en train de nous remonter tous les topics de la cat SQL, avec des réponses en mode "pavé" à chaque fois. Il est chaud