Discussion :

[llaffont]

Bonjour à tous !

J'ai plusieurs années d'expérience dans l'utilisation des tables mais je n'ai pas forcément toutes les bases ni les bons réflexes.

Aujourd'hui j'ai besoin de faire une configuration assez propre car mon projet est repris par un tiers.

J'ai besoin de faire des liaisons entre mes tables et c'est une première pour moi

J'ai trois tables :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
-- --------------------------------------------------------
 
--
-- Structure de la table `Appli`
--
 
CREATE TABLE IF NOT EXISTS `Appli` (
  `IDAppli` int(11) NOT NULL AUTO_INCREMENT,
  `nomAppli` varchar(60) NOT NULL,
  `Position` int(10) NOT NULL,
  PRIMARY KEY (`IDAppli`)
) ENGINE=MyISAM  DEFAULT CHARSET=ascii;
 
-- --------------------------------------------------------
--
-- Structure de la table `Indicateurs`
--
 
CREATE TABLE IF NOT EXISTS `Indicateurs` (
  `IDIndic` int(11) NOT NULL AUTO_INCREMENT,
  `nomIndic` varchar(20) NOT NULL,
  PRIMARY KEY (`IDIndic`)
) ENGINE=MyISAM  DEFAULT CHARSET=ascii;
 
-- --------------------------------------------------------
--
-- Structure de la table `conf_appli`
--
 
CREATE TABLE IF NOT EXISTS `conf_appli` (
  `IdAppli` int(11), 
  `IdIndic` int(11), 
) ENGINE=MyISAM DEFAULT CHARSET=ascii;

La table "conf_appli" ce réfère aux index des tables Indicateurs et Appli

Ma conception me semble correct mais je suis sûr que l'on peu faire mieux.

Pourriez vous m'aiguiller ?

[qi130]

1 virgule en trop dans conf_appli

Es-tu obligé de travaillé en MyISAM ?

Parce que je sens bien le moteur InnoDB pour gérer les foreign key entre conf_appli et les autres tables. Ainsi, l'intégrité référentielle serait gérée par MySQL et pas via l'application.

[ok.Idriss]

Bonjour.

Es-tu obligé de travaillé en MyISAM ?

Parce que je sens bien le moteur InnoDB pour gérer les foreign key entre conf_appli et les autres tables. Ainsi, l'intégrité référentielle serait gérée par MySQL et pas via l'application.

Tout à fait d'accord mais il est toujours mieux de la gérer également via l'application (un message d'erreur du SGBD n'est pas toujours ce qu'il y a de plus agréable pour un utilisateur lambda).

Donc +1 pour utiliser le moteur InnoDB (surtout dans ce contexte). Il est également nécessaire de créer des contraintes de clefs étrangères et de clefs primaires dans la table conf_appli qui fait la liaison des deux autres tables.

On peut donc exécuter ces requêtes (si la table conf_appli est déjà crée) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
ALTER TABLE conf_appli ADD FOREIGN KEY (IdAppli) REFERENCES Appli(IDAppli);
 
ALTER TABLE conf_appli ADD FOREIGN KEY (IdIndic) REFERENCES Indicateurs (IDIndic);
 
ALTER TABLE conf_appli ADD PRIMARY KEY (IdAppli, IdIndic);

Cordialement,
Idriss

[CinePhil]

Tout à fait d'accord mais il est toujours mieux de la gérer également via l'application (un message d'erreur du SGBD n'est pas toujours ce qu'il y a de plus agréable pour un utilisateur lambda).

Ce qui est encore mieux, c'est que l'application récupère et traite le message d'erreur donné par le SGBD afin de guider clairement l'utilisateur, notamment dans sa langue, sur ce qui ne va pas.

[llaffont]

Merci pour vos réponses.

J'ai opté pour

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
 
 
--
-- Structure de la table `applimobil`
--
 
CREATE TABLE IF NOT EXISTS `applimobil` (
  `idAppli` int(11) NOT NULL AUTO_INCREMENT,
  `nomAppli` varchar(60) NOT NULL,
  `Position` int(10) NOT NULL,
  PRIMARY KEY (`idAppli`)
) TYPE=INNODB;
 
 
-- --------------------------------------------------------
--
-- Structure de la table `indicateurs`
--
 
CREATE TABLE IF NOT EXISTS `indicateurs` (
  `IDIndic` int(11) NOT NULL AUTO_INCREMENT,
  `nomIndic` varchar(20) NOT NULL,
  PRIMARY KEY (`IDIndic`)
) TYPE=INNODB;
 
 
 
-- --------------------------------------------------------
--
-- Structure de la table `conf_applicharge`
--
 
CREATE TABLE IF NOT EXISTS `conf_applicharge` (
	`IdApplicharge` int(11) NOT NULL AUTO_INCREMENT,
	`IdAppli` int(11) NOT NULL,
	`IdIndic` int(11) NOT NULL,
	PRIMARY INDEX (IdApplicharge),
  FOREIGN KEY (IdAppli) REFERENCES `applimobil` (idAppli),
  FOREIGN KEY (IdIndic) REFERENCES `indicateurs` (IDIndic)
) TYPE=INNODB;

[ok.Idriss]

C'est bien, sauf que si tu veut que les couples (IdAppli, IdIndic) soient uniques (comme je n'en sais rien, je te préviens au cas où ), la clef primaire doit être la concaténation des deux clefs étrangères.

Autrement dit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
CREATE TABLE IF NOT EXISTS `conf_applicharge` (
    `IdAppli` int(11) NOT NULL,
    `IdIndic` int(11) NOT NULL,
    FOREIGN KEY (IdAppli) REFERENCES `applimobil` (idAppli),
    FOREIGN KEY (IdIndic) REFERENCES `indicateurs` (IDIndic),
    PRIMARY KEY (IdAppli, IdIndic)
) TYPE=INNODB;

Cordialement,
Idriss

[llaffont]

Merci j'en prends note on ne sait jamais si un jour cela peux me servir.

Dans le cas présent la table 'conf_applicharge' ne sert juste à conserver l'état de checkbox.

Le 'IdApplicharge' ne me sert à rien.

[CinePhil]

Ben si idapplicharge ne te sert à rien, supprime-le !

[gene69]

pour quelle collation optes-tu? personnellement j'apprecie UTF8-general-ci parce que

1. insensible à la casse
2. accepte assez bien les choses comme les oe entrelacés et les autres fioritures qu'on peut trouver dans les mots issus des langues européennes.

plus au cas par cas du binaire pour ce que je ne suis pas sensé modifier (images, documents, hash, certificats )

[llaffont]

Merci à tous.

J'ai opté pour INNODB et de l'utf8_general_ci.

Tout fonctionne