relation 1:1 entre tables

Le
Stan
Bonjour,

Je voudrais connaitre les avantages et le inconvénients d'avoir
une table des relation 1:1 entre tables.
Quand je conçois un model de base, j'ai une tendance naturelle
à sépararer les informations de manière logique, et pour cela
j'utilise des relations 1:1 entre les différentes tables quand s'est
nécessaire.

Cependant, j'entends dire parfois qu'une relation 1:1 n'a pas lieu
d'être, et on "m'oblige" à mettre toutes les informations dans la même
table.

Qu'en pensez vous ?
En terme de performance, de maintenance etc


PS: j'utilise MySql5

--
-Stan
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
comico
Le #21878881
"Stan" fionhs$doj$
[...]
Cependant, j'entends dire parfois qu'une relation 1:1 n'a pas lieu
d'être, et on "m'oblige" à mettre toutes les informations dans la même
table.

Qu'en pensez vous ?



Bonjour

Les relations 1->1 sont très classiques et ont lieu d'être !
Exemple : 1 client a 1 code statistique (table client) mais ce code pointe
sur un libellé (table statclient)

Parfois, pour optimiser , on utilise également un lien 1->1 pour "répartir"
des champs
Exemple:: table client (CodeClient identifiant) , table clientsuite
(CodeClient identifiant)
On peut utiliser ce schéma pour répartir "champs usuels" / "champs non
usuels" ou également pour séparer les blobs des "champs usuels"
Bon ce schéma ne se justifie qu'en cas de souci de performance (constaté ou
prévu) ou de limite atteinte (nombre de champs max pour une table atteint)

Les règles de normalisation sont souvent bien décrites dans la littérature,
les astuces de dénormalisation viennent souvent de l'expérience du
développeur.
Pour résumer il me semble que le "on" qui vous oblige à mettre toutes les
informations dans la même table a tort !
Stan
Le #21878871
"comico" 4752dffb$0$28301$

On peut utiliser ce schéma pour répartir "champs usuels" / "champs non
usuels" ou également pour séparer les blobs des "champs usuels"



C'est dans cette optique que je voulais séparer des champs à caractère
'volatile'
de champs peu modifiés;

Bon ce schéma ne se justifie qu'en cas de souci de performance (constaté
ou
prévu) ou de limite atteinte (nombre de champs max pour une table atteint)




On m'a répondu qu'on 'verra quand ça se présentera' ....

Les règles de normalisation sont souvent bien décrites dans la
littérature,
les astuces de dénormalisation viennent souvent de l'expérience du
développeur.
Pour résumer il me semble que le "on" qui vous oblige à mettre toutes les
informations dans la même table a tort !




Sans doute, mais comme je n'avais pas tout les arguments
pour faire pencher la balance...

--
-Stan
Publicité
Poster une réponse
Anonyme