Discussion :

[boby62423]

Bonjour,

Je me pose la question de savoir quelle est la meilleure architecture pour stocker une famille dans une base de données.

La famille est composée:
- Du père
- De la mère
- Des enfants

La famille a la même adresse.

Le père & la mère ont chacun un nom, un prénom, un age, etc. plus un certain nombre de paramètres spécifiques pour mon application

Les enfants ont eux aussi un nom, un prénom et un age plus des paramètres spécifiques de format différent des paramètres des parents

Enfant, l'ensemble de la famille doit avoir un seul et même numéro. L'adresse est commune à toute la famille.

Je voudrais savoir quelle est la meilleure solution pour structurer la base (sachant que je compte utiliser linq pour travailler en objet)

J'ai fait ceci:

Une table famille:
- N° Famille en clef primaire
- Adresse

Une table parents:
- N° parent en clef primaire
- N° Famille en FK sur la table famille
- Un champ qui permet de savoir si c'est le pere ou la mere
- Un champ Nom, prenom
- Mes champs spécifiques

Une table enfants:
- N° enfant en clef primaire
- N° Famille en FK sur la table famille
- Un champ nom prenom, etc...
- Mes champs spécifiques

=> J'ai réfléchis par A+B et cela me semble être la meilleure solution.

Cependant, on m'a conseillé de supprimer la table famille mais cela me gène pour deux raisons:
- Le champ adresse sera en double (quoi que on peut imaginer des cas ou le père et la mère sont séparés
- Il n'y a plus de N° de famille donc la structure ressemble à ça:

Une table parents:
- N° Famille en Clef Primaire
- Un champ qui permet de savoir si c'est le pere ou la mere en Clef Primaire aussi
- Un champ Nom, prenom
- Mes champs spécifiques

Une table enfants:
- N° enfant en clef primaire
- N° Famille en FK sur la table parents => Big problème ici car on fait une FK sur une moitié de clef primaire !
- Un champ nom prenom, etc...
- Mes champs spécifiques

Donc voila n'hésitez pas à me dire si ma solution est correcte ou si c'est de la grosse merde.
Je cherche vraiment la perfection donc allez y franco. Peut être qu'il existe d'autres solutions que je n'ai pas imaginé donc n'hésitez pas !

D'avance merci

A+

[jero44]

Bonjour,
Votre première solution suppose que pour toutes les familles il n'existe qu'une seule adresse. Bien que ce soit fréquent, ce n'est pas toujours le cas.
Je serais tenté de faire un mix entre la solution 1 et 2 à savoir:
Conserver la table des familles avec l'adresse et tous les renseignements commun à la famille (tel, ....)
Compléter la table des parents avec l'adresse en saise optionnelle. Ainsi par défaut on fait référence aux informations de la famille sauf si des information au niveau Parent sont stockées. Cela permet de couvrir les familles séparés.

[jero44]

Désolé d'aborder le problème en 2 temps mais il me semble que votre modèle gère difficilement les familles recomposées.
Je vous propose donc le modèle suivant:

Une table familles:
- N° Famille en clef primaire
- Adresse
- Pere en FK sur la table Parents
- Mere en FK sur la table Parents

Une table parents:
- N° parent en clef primaire
- Adresse (option
- Un champ Nom, prenom
- Vos champs spécifiques

Une table enfants:
- N° enfant en clef primaire
- N° Famille en FK sur la table famille
- Un champ nom prenom, etc...
- Vos champs spécifiques

[elsuket]

Bonjour,

Je ne trouve pas que la propriété adresse d'une famille la définisse, et je placerai donc les adresses dans une table à part.

Big problème ici car on fait une FK sur une moitié de clef primaire !

Ceci est faux, et en conséquence impossible

Une table familles:
- N° Famille en clef primaire
- Adresse
- Pere en FK sur la table Parents
- Mere en FK sur la table Parents

Pareil dans le cas d'une famille mono-parentale, il faut que les deux clés étrangères de cette table soient optionnelles mais qu'au moins l'une des deux soit valuée.
Dans le cas d'une famille recomposée, est-on certain que les enfants nés des deux unions de leurs parents font "partie" de la famille recomposée ?

@++

[Keihilin]

Quelques remarques :

• Lier l'adresse à la notion de famille est sémantiquement faux. Soit on parle de famille et dans ce cas la notion géographique n'a rien à faire là, soit on parle de ménage et là, effectivement, l'adresse a un sens. Mais quoiqu'il en soit, il faut une table séparée pour les adresses.
• Avoir une table "PARENTS" et une table "ENFANTS" me paraît moyennement judicieux, sauf si ces deux tables héritent d'une table "PERSONNE" contenant les informations communes.
• La relation familiale devrait justement être modélisée par une table supplémentaire et surtout pas par une colonne dans la table "PARENTS" qui indique si c'est la père ou la mère de la famille : Comment vas-tu faire le jour où tu voudras gérer les frères et soeurs, les oncles et tantes et les grands-parents ?