Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Applications Applications SGBD On se mord la queue.... comment faire....

On se mord la queue.... comment faire....

11 réponses
Avatar
PRORIOL Fabien
Bonjours,

Je travail avec MySQL 4.1.7.
J'utilise des table InnoDB et je gère donc mes relations.

Ma question :
J'ai deux tables :

CREATE TABLE `contact` (
`id` int unsigned NOT NULL auto_increment,
`nom` varchar(30) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`prenom` varchar(30) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`email` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`adresse` text CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`tel` varchar(16) CHARACTER SET utf8 COLLATE utf8_general_ci,
`portable` varchar(16) CHARACTER SET utf8 COLLATE utf8_general_ci,
`fax` varchar(16) CHARACTER SET utf8 COLLATE utf8_general_ci,
`login` varchar(30) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
PRIMARY KEY (`ID`)
) TYPE=InnoDB;

CREATE TABLE `users` (
`login` varchar(30) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`motdepass` varchar(30) CHARACTER SET utf8 COLLATE utf8_general_ci
NOT NULL,
`fonction` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci
NOT NULL,
`contact` int unsigned NOT NULL,
PRIMARY KEY (`login`),
KEY `contact` (`contact`),
FOREIGN KEY (`contact`) REFERENCES `contact` (`id`)
) TYPE=InnoDB;

En effet, le 'users' est un 'contact' particulier; d'ou la clé étrangère.

Mais voila, le 'contact' est lui même créé par un 'users' sauf 1 qui est
le root.
Je voulais donc avoir une clé étrangère dans la table contact (le champ
'login') qui relie a la table users, mais voila, on se mord la queue!!!!!

Comment faut-t-il faire?

Merci,
@+Fab
Signaler un problème avec ce contenu

10 réponses

Supprimer
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
1 2
Avatar
PRORIOL Fabien
Personne a la reponse???
Je ne pense pas que se soit un probleme impossible a resoudre si???
Ou alors je fait une erreur au niveau conception....
comment je peut m'y prendre autrement?

@+Fab

Bonjours,

Je travail avec MySQL 4.1.7.
J'utilise des table InnoDB et je gère donc mes relations.

Ma question :
J'ai deux tables :

CREATE TABLE `contact` (
`id` int unsigned NOT NULL auto_increment,
`nom` varchar(30) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`prenom` varchar(30) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`email` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`adresse` text CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`tel` varchar(16) CHARACTER SET utf8 COLLATE utf8_general_ci,
`portable` varchar(16) CHARACTER SET utf8 COLLATE utf8_general_ci,
`fax` varchar(16) CHARACTER SET utf8 COLLATE utf8_general_ci,
`login` varchar(30) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
PRIMARY KEY (`ID`)
) TYPE=InnoDB;

CREATE TABLE `users` (
`login` varchar(30) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`motdepass` varchar(30) CHARACTER SET utf8 COLLATE utf8_general_ci NOT
NULL,
`fonction` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT
NULL,
`contact` int unsigned NOT NULL,
PRIMARY KEY (`login`),
KEY `contact` (`contact`),
FOREIGN KEY (`contact`) REFERENCES `contact` (`id`)
) TYPE=InnoDB;

En effet, le 'users' est un 'contact' particulier; d'ou la clé étrangère.

Mais voila, le 'contact' est lui même créé par un 'users' sauf 1 qui est
le root.
Je voulais donc avoir une clé étrangère dans la table contact (le champ
'login') qui relie a la table users, mais voila, on se mord la queue!!!!!

Comment faut-t-il faire?

Merci,
@+Fab
Avatar
Patrick Mevzek
Le Thu, 06 Jan 2005 16:52:00 +0100, PRORIOL Fabien a écrit :
Personne a la reponse???



Usenet n'est pas un guichet unique de réponse à toutes les questions avec
temps de réponse garanti :-)

Je ne pense pas que se soit un probleme impossible a resoudre si??? Ou
alors je fait une erreur au niveau conception....



J'ose pencher pour cette hypothèse.

comment je peut m'y prendre autrement?



Personnellement, j'ai bien essayé de trouver une réponse à votre
problème, mais pour le moment je ne comprends même pas ce que vous
modélisez exactement.

En particulier, pourquoi un attribut ``login'' dans contact, puisque
j'avais l'impression que c'était la table users qui gérait cela.

Bref, je pense que vous aurez davantage d'aide si vous commenciez par
expliquer plus en détails les données que vous manipulez.

PS: il ne faut pas mettre les dents :-) !

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Avatar
PRORIOL Fabien
Usenet n'est pas un guichet unique de réponse à toutes les questions avec
temps de réponse garanti :-)


Je sait bien ;-)


Personnellement, j'ai bien essayé de trouver une réponse à votre
problème, mais pour le moment je ne comprends même pas ce que vous
modélisez exactement.


En d'autre mots, sur mon site j'utilise un systeme d'administrateur par nom et mot de passe.
Avant cela, j'ai une table qui contient des 'Contacts', ce sont les donnée personnelle concernant une personne (adresse, email.....)
Elle sert pour pas mal de chose dans mon site (president d'assoc, responsable de commerce.....)
Mais un 'users' (un administrateur du site) est une personne qui peut acceder a la partie administrateur, et selon une liste de droit qui lui est
attribuer, il peut acceder a certain formulaire pour ajouter/modifier/supprimer des truc sur le site (actualité, assoc, manif....)
Mais voila, un user doit etre lier a un contact pouisque ses donnée personnelle sont contenu dans la table contact.
(d'ou le lien du contact avec le users)

Par contre, pour chaque formulaire, j'ai 2 types de droit.
Dans tout les cas, si le droit est donné le users peut faire un ajout.
La difference entre les 2 types de droit est le suivant :
- s'il est ordinaire, il ne peut QUE modifier ou supprimer ce qu'il a créé (pas de visibilité sur les objet créé par d'autre).
- s'il a les superdroit il est capable de modifier/supprimé les objet créé par n'importe qui.

Pour cela, chaque fois qu'un objet (actu, assoc, artisan, photos....) est créé, j'enregistre dans la table le 'login' du createur (sa clé primaire)

Les contact n'echappe pas a cette regle (sauf le root qui est créé au debut), il sont créé par des users, donc j'aimerai avoir dans contact une clé
etrangere relier au createur de cet objet.
Il est ici le PB, un user est lier a un contact qui est lier a un user, et en SQL j'ai l'impression que C impossible.


Voila, j'espere que sa pourra vous aider a mieu comprendre

Pour info (mais je ne pense pas que sa va vous aider) mon site se trouve a l'adresse http://saint-pal.com/test/homepage.php5

Merci pour vos reponse ;-)

@+Fab
Avatar
Côme de Christen
Salut

Pour ma part je pencherais pour une seule table user !
Le "root" ne serait pas dans cette table (il peut être stocké dans une table "system")
Tout devient alors plus clair non ?
A la connexion 2 solutions, soit on précise son type d'accès (root ou user), soit on
a 2 connexions différentes.
M'enfin je connais pas le contexte hein, j'imagine :-)
Avatar
Côme de Christen
"PRORIOL Fabien" a écrit dans le message de news:
crjras$ogp$
[...]
Il est ici le PB, un user est lier a un contact qui est lier a un user, et en SQL j'ai
l'impression que C impossible.


[...]

C'est pas une histoire de SQL mais de logique !
Vos contraintes sont impossibles à respecter.
Avatar
Fred BROUARD - SQLpro
Côme de Christen a écrit:
"PRORIOL Fabien" a écrit dans le message de news:
crjras$ogp$
[...]

Il est ici le PB, un user est lier a un contact qui est lier a un user, et en SQL j'ai
l'impression que C impossible.



[...]

C'est pas une histoire de SQL mais de logique !
Vos contraintes sont impossibles à respecter.



détrompe toi, des contraintes circulaires sont possible si le SGBDR gère la
déférabilité... mais connaissant MySQL, il en est à 100 000 lieux !

A lire :
http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=partie2#L7.4

A +






--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Avatar
PRORIOL Fabien
détrompe toi, des contraintes circulaires sont possible si le SGBDR gère
la déférabilité... mais connaissant MySQL, il en est à 100 000 lieux !


aie aie aie.....

Donc c'est mort en MySQL.... :-(

Bon, ma solution 'rustine' serais de ne pas mettre le users.contact en clé etrangere et de le géré a la main (commme avant quand MySQL ne géré pas les
relation....
C'est pas tres propre en tout cas, mais c'est table ne sont pas tres dynamique, elle changerons pas beaucoup alors finalement, sa pourrais etre une
solution de remplacement....

Merci de vos reponses

Si vous voyait une meilleur solution merci de m'en faire part....

@+Fab
Avatar
Côme de Christen
"Fred BROUARD - SQLpro" a écrit dans le message de news:
41dd7557$0$31530$
Côme de Christen a écrit:
"PRORIOL Fabien" a écrit dans le message de news:
crjras$ogp$
[...]
Il est ici le PB, un user est lier a un contact qui est lier a un user, et en SQL j'ai
l'impression que C impossible.


[...]

C'est pas une histoire de SQL mais de logique !
Vos contraintes sont impossibles à respecter.



détrompe toi, des contraintes circulaires sont possible si le SGBDR gère la déférabilité... mais
connaissant MySQL, il en est à 100 000 lieux !

A lire :
http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=partie2#L7.4



Merci je ne connaissais pas cette notion !
Alors Fabien n'a qu'à prendre Oracle et tout ira pour le mieux alors :-))
Avatar
Patrick Mevzek
Le Thu, 06 Jan 2005 18:28:08 +0100, Fred BROUARD - SQLpro a écrit :
détrompe toi, des contraintes circulaires sont possible si le SGBDR gère
la déférabilité... mais connaissant MySQL, il en est à 100 000 lieux !

A lire :
http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=partie2#L7.4



Même si la solution existe (et je crois que PostgreSQL la supporte), il
me semble que l'exemple proposé n'est pas très significatif, je ne vois
pas du tout l'intérêt de stocker la dernière commande du client dans la
table client, vu que c'est une information redondante, qu'on construit
trivialement à partir de la table commande, donc aucun intérêt de la
stocker explicitement (cela me parait même violer les standards de la
normalisation), et si on le veut vraiment on peut toujours le
faire dans une autre table qui ne s'occuperait que de ca.

D'autre part dans un tel cas de figure, la base deviendra très rapidement
incohérente: il faudrait ajouter un trigger pour faire la mise à jour
automatiquement (de la table commande vers la table client).

Bref, même si on peut trouver une solution, je trouve qu'on cherche une
solution à un faux problème.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Avatar
Patrick Mevzek
Le Thu, 06 Jan 2005 18:10:13 +0100, PRORIOL Fabien a écrit :
Usenet n'est pas un guichet unique de réponse à toutes les questions
avec temps de réponse garanti :-)


Je sait bien ;-)



Ne soyez pas si impatients alors, il n'y avait pas même 24h entre vos
deux posts :-)

Pour cela, chaque fois qu'un objet (actu, assoc, artisan, photos....)
est créé, j'enregistre dans la table le 'login' du createur (sa clé
primaire)

Les contact n'echappe pas a cette regle (sauf le root qui est créé au
debut), il sont créé par des users, donc j'aimerai avoir dans contact
une clé etrangere relier au createur de cet objet. Il est ici le PB, un
user est lier a un contact qui est lier a un user, et en SQL j'ai
l'impression que C impossible.



Avec ces détails, c'est déjà plus clair :-)
Personnellement je pense que votre vrai problème est dans votre schéma,
et que donc la ``solution'' des réfèrences circulaires est une mauvaise
solution. Pas parce qu'elle ne pourra être utilisée que dans certains
SGBDR, mais parque que ce n'est pas la solution au bon problème. Cf mon
autre post plus loin à ce sujet précis.

J'ai des applications avec des fonctionnalités très similaires aux
votres.
Si j'adapte avec votre terminologie:
- vous faites une table contact, avec toutes les propriétés des
personnes, dont un attribut created_by qui est une référence sur la clef
primaire de *cette* même table
- vous faites une table users, qui référence la clef primaire de la table
contact, et qui ne contient que les droits d'accès, etc...

Ainsi plus de références circulaires entre plusieurs tables, et plus de problèmes.
A la création, vous créez root qui pointe sur lui-même, après quoi vous
pouvez insérer des contacts créés par root, et ainsi de suite en cascade.

Cela permet de gérer en plus le cas où vous donnez à un moment un accès à
un contact comme utilisateur du site donc, et après vous lui enlevez son
accès (mais le conservez en tant que personne donc).
Dans ce cas de figure, vous le faite disparaitre de la table users, et
toutes les liaisons de contact sur elle-même (pour noter quels contacts
ont été créés par cette personne) continuent d'être bonnes.
Vous aurez bien plus de problèmes à gérer ce cas de figures en cas de
références croisées entre 2 tables.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
1 2