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.