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...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
comico
"Stan" a écrit dans le message de news: 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" <none@none.invalid> a écrit dans le message de news:
fionhs$doj$1@s1.news.oleane.net...
[...]
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" a écrit dans le message de news: 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
"comico" a écrit dans le message de news: 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
"comico" <come.dechristen@wanadoo.fr> a écrit dans le message de news:
4752dffb$0$28301$426a74cc@news.free.fr...
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...
"comico" a écrit dans le message de news: 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...
