Bonjour,

Ayant remarqué que mon post sur le même sujet n'étais pas clair je recommence ici proprement.

Je dois concevoir une application web (php / mysql), projet scolaire:

Je dois créer une base de donnée dans laquelle se trouvera les tables suivantes (je ne parlerai que de mon problème, le reste n'est pas utile ici)

* une table UTILISATEURS
* une table SOCIETE
* une table SITE_DEXPLOITATION

voici le détails des table (allégé):

CREATE TABLE UTILISATEUR (
PK_UTILISATEUR INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
LOGIN VARCHAR( 20 ) NOT NULL UNIQUE,
MDP VARCHAR(32) NOT NULL
) ENGINE = InnoDB;

CREATE TABLE SOCIETE (
PK_SOCIETE INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
NOM_SOCIETE VARCHAR( 50 ) NOT NULL,
ADRESSE_SOCIETE VARCHAR(50) NOT NULL
) ENGINE = InnoDB;

CREATE TABLE SITE_EXPLOITATION (
PK_SITE INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
NOM_SITE VARCHAR( 50 ) NOT NULL,
ADRESSE_SITE VARCHAR(50) NOT NULL,
FK_SOCIETE INT NOT NULL,
INDEX IDX_FK_SOCIETE (FK_SOCIETE),
FOREIGN KEY (FK_SOCIETE) REFERENCES SOCIETE(PK_SOCIETE) 
) ENGINE = InnoDB;

//La foreign key conserve bien l'intégrité référentielle (je crois )



Mon problème est le suivant, je dois à partir de ces tables trouve une solution pour qu'un utilisateur:
X puisse accéder à la société X
Y puisse accéder à la société X,Y, ...
Z puisse accéder à toute les sociétés (admin)

Je pense utiliser un système de grade pour les droits (édition, suppression, modification) [ALTER TABLE UTILISATEUR] + [CREATE TABLE GRADE]

Mais comment puis-je en SQL dire que X à le droit de voir X , Y à le droit de voir X,Y, ... et Z à le droit de tout voir...
J'ai pensé à une table qui utiliserait les clés primaire de cette manière:
PK_X , PK_SOCIETE_X
PK_Y , PK_SOCIETE_X
PK_Y , PK_SOCIETE_Y
PK_Y , PK_SOCIETE_...
PK_Z , PK_SOCIETE_ALL

Cette solution ne me plait pas parce que je ne l'ai jamais mis en œuvre auparavant, mais elle existe et porte un nom qui m'échappe...

Merci de m'éclairer si vous le pouvez (je dois faire une représentation UML de ce que je pense être une "association" si vous savez comment faire ca aussi, je prend le tout )

Soit tu gères les droits dans la base de données, mais alors il faut un compte utilisateur de BDD par utilisateur de ton site. Ensuite tu supprimes tous les privilèges de tous les utilisateurs sur toutes les tables, et ils n'ont que le droit de faire des SELECT ou du DML sur des VIEW (qui vérifient les droits en lecture) et tu mets des triggers pour intercepter les écritures et vérifier les droits. C'est le souc.

Soit tu gères les droits dans l'application et donc là t'as une relation N-N comme tu as dit, plus l'admin qui est un cas à part, tu le vires de ton UML donc.

Tu peux aussi faire des groupes (genre tels machins appartiennent à un groupe, un utilisateur a des droits sur un groupe, après tu fais un arbre avec tes groupes comme pour les droits de modération des forums, etc).

Ma base de donnée est assez simple, la gestion des utilisateurs dans la BD n'est une bonne idée pour moi (et pr ce projet)

Je vais travailler une relation n-n avec une table d'association via le code de l'application.

create table association_user_societe{
FK_UTILISATEUR int not null,
FK_SOCIETE int not null,
}

Je dois conserver l'intégrité référentielle avec des clause index et foreign ??? (je pense que oui)
Dois-je ajouter une clé primaire (ce n'est pas une table classique je pense que non)

Foreign key / relations : oui, indispensable.

Clé primaire : (utilisateur_id,societe_id), c'est unique et ça caractérise parfairement la ligne, pas d'id en auto-increment dans ce genre de table

Index : la clé primaire créé un index sur (utilisateur_id,societe_id) mais pour les performances tu peux en ajouter un autre avec les colonnes inversées (societe_id,utilisateur_id)

create table association_user_societe{
FK_UTILISATEUR int not null,
FK_SOCIETE int not null,
index IDX_ASSOC_US(FK_UTILISATEUR,FK_SOCIETE),
FOREIGN KEY (FK_UTILISATEUR) REFERENCES (PK_UTILISATEUR),
FOREIGN KEY (FK_SOCIETE) REFERENCES (PK_SOCIETE)
}

Serait-ce correcte? ou dois-je utiliser une foreign key combinatoire (je ne ss pas si ca existe sous mysql)

FOREIGN KEY (FK_UTILISATEUR,FK_SOCIETE) REFERENCES (PK_UTILISATEUR, PK_SOCIETE)

si je rajouter l'élément ON DELETE CASCADE, je supprime automatiquement les éléments liés enfant lors de la suppression de l'élément liés parent (je pense avoir compris ça)

Serais-ce judicieux pour purger ma table en cas de suppression de l'elements PK_UTILISATEUR (suppression de tt le tuple)
Est ce que le société sera supprimé aussi?

Merci pour ces infos, j'avance dans la suite maintenant

C'est correct mais t'as oublié la PK.

Sinon, si la table utilisateurs a comme PK utilisateur_id, alors donne le même nom à la colonne dans association_user_societe. Ça te permet d'utiliser JOIN USING et c'est immédiatement lisible.

La foreign key style (a,b) c'est si tu références (a,b) qui sont dans la même table. Ici tu as 2 tables à référencer donc 2 FK.

> Serais-ce judicieux pour purger ma table en cas de
> suppression de l'elements PK_UTILISATEUR

A toi de voir si tu mets ON DELETE RESTRICT ou CASCADE... là je mettrais CASCADE puisque si tu vires l'user, tu vires aussi ses droits...

> Est ce que le société sera supprimé aussi?

Ça ne cascade que dans un sens (suis les flèches sur ton diagramme de relations)

Merci de ces lumières, je pense faire ceci

create table association_user_societe{
FK_UTILISATEUR int not null,
FK_SOCIETE int not null,
index IDX_ASSOC_US(FK_UTILISATEUR,FK_SOCIETE),
FOREIGN KEY (FK_UTILISATEUR) REFERENCES (PK_UTILISATEUR) ON DELETE CASCADE,
FOREIGN KEY (FK_SOCIETE) REFERENCES (PK_SOCIETE),
PRIMARY KEY (FK_UTILISATEUR,FK_SOCIETE)
}

Si tu mets une PK sur (FK_UTILISATEUR,FK_SOCIETE) ça créé déjà un index, donc l'autre index il faut le mettre sur (FK_SOCIETE,FK_UTILISATEUR) pour accélérer les recherches sur FK_SOCIETE...

create table association_user_societe{
FK_UTILISATEUR int not null,
FK_SOCIETE int not null,
index IDX_ASSOC_US(FK_UTILISATEUR,FK_SOCIETE),
FOREIGN KEY (FK_UTILISATEUR) REFERENCES (PK_UTILISATEUR) ON DELETE CASCADE,
FOREIGN KEY (FK_SOCIETE) REFERENCES (PK_SOCIETE),
PRIMARY KEY (FK_SOCIETE,FK_UTILISATEUR)
}

On apprend pas ca à l'école bien dommage vive l'optimisation à moindre frais de ressource