Discussion :

[Arkante]

Bonjour,

J'ai un profil utilisateur qui peut contenir plusieurs téléphones et addresses.

La premiere chose qui vient en tête serait de faire trois tables (profil, telephone et adresse) avec des relations 1:n.

Cependant je pensais regrouper téléphone et addresse en une seule table. En gros avoir les champs de l'un et de l'autre a la suite. L'intérêt est de limiter le nombre de "join" dans les requêtes et donc d'augmenter la performance.

Ce qui me dérange c'est que une adresse se retrouve avec un téléphone alors qu'ils n'ont aucun rapport.

Vous en pensez quoi ?

[al1_24]

Tu as trouvé tout seul la réponse

Ce qui me dérange c'est que une adresse se retrouve avec un téléphone alors qu'ils n'ont aucun rapport.

Il faut bien trois tables. D'autant que le nombre d'adresses et de téléphones n'est pas obligatoirement le même.

Un SGBDR est fait pour effectuer des jointures. S'il y a des index aux bons endroits, ça devrait se passer très bien

[SQLpro]

Certains téléphone sont fixe dont liés à une adresse et d'autre pas (GSM). Il faut donc bien une table des personnes, une table des adresse, un des mails, une des téléphones. éventuellement lier certains téléphones à une adresse.

Voyez le MCD/MPD que j'ai fait pour HOTEL: http://sqlpro.developpez.com/cours/bddexemple/

A +

[Arkante]

Merci pour vos réponses mais est-ce vraiment grave que le téléphone n'ait pas de lien avec le téléphone et qu'il n'y ait pas le même nombre de chaque ?

Il suffit que l'application fetch ce dont elle a besoin seulement. Mais comme les téléphones et adresses seront souvent requêtés ensemble, ca fait un join de moi (et même deux si jamais on ajoute les mails).

Ma question est surement plus général. Est-ce que j'ai intérêt de laisser le software faire une partie du boulot du sgbd pour le soulager ?

[SQLpro]

A votre avis un SGBD relationnel c'est fait pour faire des relations ou pour faire des fichiers COBOL ???
Ben entendu placer le téléphone au même niveau que l'individu sera mauvais en terme de performances !
Ce ne sont pas les jointures qui coutent, mais le cache de données que vous allez saturer en mettant tout dans la même table....

A +

[Arkante]

Ca a le mérite d'être clair.

Merci pour le feedback