Bonjour à tous,  
je suis actuellement en train de "développer" une application ayant pour but de permettre à un "administrateur de famille" de créer des nouveaux utilisateurs et ainsi leur attribuer leurs droits je m'explique : ces droits porteront sur la caméra IP ainsi qu'un disque dur IP, par exemple l'administrateur créer user 1 et dit il aura accès à la cam mais pas au dd, l'utilisateur 2 aura accès au dd mais pas à la cam, ... j'ai réalisé un MCD et ma base de données est donc constituées de 4 tables (administrateur, user, matériel, droit) donc si vous pouvez m'aider à réaliser ce système de droit, j'ai cru comprendre que les jointures SQL étaient la bonne solution mais je ne sais pas trop comment adapter les jointures SQL à mon problème.
 
Merci d'avance !

Elle est où la question, là?

comment faire pour limiter l'accès avec des jointures SQL en sachant que mes tables ressemblent à ça :
ADMIN : idADMIN (clé primaire), Nom, Prenom, Mail, mdp
USER : idUSER (clé primaire), id ADMIN(clé étrangère), Nom, Prenom, Mail, mdp
MATERIEL : idMAT (clé primaire), id ADMIN(clé étrangère),Lien
DROIT (=relation USER et MATERIEL) : idUSER et idMAT (clés étrangères)

Limiter les accès avec des jointures SQL ça veut pas dire grand chose...
Tu vas utiliser des jointures pour récupérer les droits d'un utilisateur, mais c'est tout...et ces jointures sont implicitement déjà apparentes par tes clés étrangères.

oui mais en fait je ne sais pas très bien comment créer ces clés étrangères j'ai pourtant essayé beaucoup de choses FOREIGN KEY etc ... mais ça ne marché pas alors peut être qu'il faudrait les définir à la création de la table dans une requête sql donc si quelqu'un peut m'aider pour le donner une requête pour créer les tables que je souhaite

Qu'est-ce que tu as fait pour l'isntant? Et avec quel sgbd? On manque d'info pour t'aider...

j'ai juste créer mes tables avec phpMyAdmin en définissant mest clés primaires mais pas les clés étrangères

Ben rajoute les clés étrangères. L'interface devrait permettre ça.

Sans vouloir critiquer gratuitement (c'est pas mon genre   ), je ne comprends rien à la représentation que tu fais de ton problème....
Je pense que tu poses mal ton problème et que ton modèle n'est pas correct...
SI tu veux faire de l'administration de droits, qqch comme ca serait plus logique
GROUPE : idGROUPE (clé primaire), idADMIN (qui est juste l'idUSER de l'admin), NomGROUPE
USER : idUSER (clé primaire), idGROUPE(clé étrangère), Nom, Prenom, Mail, mdp
MATERIEL : idMAT (clé primaire), Lien (j'ai enlevé idADMIN car je ne vois aps ce qu'il vient faire)
DROIT (=relation USER et MATERIEL) : idUSER et idMAT (clés étrangères)
 
Toutes les notions de clés primaires, étrangères, .... c'est bien, mais ce n'est pas ca qui vas créer ton SQL et qui va faire tes jointures... Il va boen falloir que tu utilises des INNER JOIN ou LEFT JOIN ou RIGHT JOIN ....
 
=> Que veux-tu obtenir à la fin en terme de résultats de requêtes ?

non skeye l'interface de phpMyAdmin ne permet pas de rajouter des clés étrangères et  quand à babass c gentil mais ton MCD ne permet de réaliser ce que je désire.

si l'interface ne le permet pas, tu n'as plus qu'à aller vior la doc de mysql pour écrire les requêtes à la main...

J'aime bien ce post, on a un peu l'impression de jouer à la loterie du sql.
Alors je me lance et tente un:

SELECT {...ce que tu veux ...}
FROM 
MATERIEL M
INNER JOIN DROIT D ON M.idMAT = D.idMAT
INNER JOIN USER U ON ( D.idUser = U.idUser OR U.idAdmin = M.idAdmin)
WHERE
-- AU CHOIX
U.idUser = X -- pour avoir la liste du matériel accessible par un utilisateur
M.idMAT = Y -- pour avoir la liste des users pouvant accèder à un mat

 
Mais sinon je rejoins également skeye et badass, ton modèle c'est de la daube
 

Je comprends pas trop pourquoi tu met DROIT D   USER  U    M
mais sinon merci

C'est comme cela que l'on note les alias :

• Pour des champs : monchamp AS alias_monchamp
• Pour une table  : matable alias_matable

prex  
le AS est toujours facultatif que ça soit pour un champ ou une table. J'exprime pleinement mon coté feignasse en ne les mettant pas.

Ici ils sont utiles ( et obligatoires) car plusieurs champs dans des tables différents pour le même nom ( idUser, idMAT ...).
Certains pourraient me dire "Ouais mais avec les naturals joins machins truc chouette ça marche sans alias c'est plus mieux" et la je réponds:

• ça marcherai pas dans son cas à cause de sa condition "mixte" sur User ( droit et admin)
• c'est illisible les naturals joins et sauf certains triviaux j'abhorre ...