Bonsoir,
 

 
J'ai un petit souci de comprehension sur la configuration de mon schema de base de données (MySQL 5):  
 
Je n'arrive pas à me decider si je doit conserver les clefs étrangères ou non (à cause des contraintes qui m'empêche de rentrer des données manuellement ). Il me semble que c'est hibernate qui gère les relations entre les tables, donc du coup cela vaux-t-il la peine de s'embêter avec (coté BDD) si je les declare dans mes entités ?  
 
 
Merci, par avance.

bah disons que t'es pas "obligé" mais quand tu commenceras à réaliser tes entités, tu seras bien content de savoir si ton insertion avec hibernate par exemple, fonctionne correctement et donc respecte l'intégrité de ta base.

J'ai rien compris, j'ai l'impression que tu mélanges un peu tout.
Donc déjà, en laissant mysql, nhibernate et java de côté, est ce que tu es sûr d'avoir bien compris ce qu'est une clé étrangère et surtout à quoi sert l'intégrité référentielle dans une bdd relationnelle ?
Si oui tu devrais pouvoir répondre tout seul à ta question sans avoir à réfléchir à toutes les technos que tu mentionnes.

J'ai très bien compris a quoi cela sert seulement je me suis retrouver dans plusieurs cas où :
 
1) Avec un gars soi-disant 40 ans de métier dans la bdd, où il m'explique qu'il se moquait des clef étrangères et relations, bref il ne travaillaient qu'avec des jointures. ( )
2) La quasi totalité des tuto Spring les mecs se moquent des clef étrangères, cependant dans certain blog d'autres respectes à la lettre ces relations.  
 
Bref ma question est simple qu'elle est la bonne pratique à utiliser, professionnellement parlant ?
 
A) Dans ma bdd je declare pratiquement rien (ouste les contraintes et clef étrangères), mais je les declare tout de même dans ma couche java métier (Hibernate / JPA et model) et du coup c'est hibernate qui gère la coherence)
B) Je declare toutes les relations et contraintes dans la bdd, puis je refais de mêmes dans la couche java métier. (voir point A).
 
Dans le point A la bdd sert juste de système de persistance pour les données et perd toutes coherences si l'on utilise pas le code java associé.
Dans le point B cela ressemble à une double sécurité inutile à moins de perdre le code applicatif.  
 
Je peux très bien comprendre que B est à privilégié dans certaines structures où certain standard sont à respecter à la lettre (banque, grosse entreprise, etc.).  
 
Seulement, je suis actuellement sur un petit projet de serveur back end sous Spring pour un petit site e-commerce pouvant évoluer vers une application SaaS haute disponibilité et hautement scalable sur le long terme et donc pour le moment (à court terme) le point A me parait amplement suffisant.
 
Du coup ça à l'air bon où je n'ai rien compris, selon vous ?

Perso le "R" de relationnel est très important pour moi, dans n'importe quel système qui maintient des données de prod jamais je ne désactive l'IR dans la base.  
Les FK ne servent pas qu'à faire joli sur les modèles !
 
De mon point de vue, dans ton code tu fais comme ça te plaît, mais c'est très important que l'intégrité soit assurée là où on en a besoin pour être sûr de ne pas avoir des données vérolées avec des records orphelins partout : dans la base de données.
 
Concernant le fait de faire apparaître les contraintes dans ton ORM, j'imagine qu'elles ne servent pas à vérifier la cohérence d'une action de façon redondante avec la BdD, mais surtout à générer les propriétés de navigation sur tes objets pour faire du lazy loading (etc). Je ne sais pas quel niveau de contrôle offre nhibernate sur ça.
 
Mais même dans le cas contraire (où effectivement nhibernate viendrait tenter de valider l'IR sans se reposer sur la base elle même), ça coûte en perf (faire le boulot deux fois), mais ça facilite la vie.
C'est comme le fait que l'ORM applique des vérifications sur les champs avant de balancer ça au SGBDR (ex : si tu essais d'écrire un string de 50 dans un varchar(30), ton ORM pourra gueuler avant même de passer l'info à la BDD) : ça a l'air redondant, mais c'est parfois utile et pratique.