Discussion :

[Antoine_935]

Salut à toutes et à tous.

Dans le cadre de mon petit projet actuel (site web pour artiste graphique), j'ai les deux tables comme définies ci-dessous:

Code :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE page (
    pageId INTEGER PRIMARY KEY,
    /* les autres champs */
)
 
CREATE TABLE config (
    name VARCHAR(255) PRIMARY KEY,
    value VARCHAR(255)
)

Sachant que j'ai, dans ma table config, un tuple enregistré comme suit:
name: "homepage"
value: "1"

Est-il valide de faire la requête suivante, en comparant donc un entier avec un varchar ?

Code :

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

1
2
3
4
SELECT p.*
FROM page p, config c
WHERE c.name = "homepage"
    AND p.pageId = c.value

Cette requête fonctionne sous MySQL, mais est-ce que c'est légal du point de vue SQL standard ?
Aussi, est-ce que c'est une solution propre ? Elle me parait un peu bizarre... voire dangereuse.

[CinePhil]

Si la colonne 'value' de la table 'config' fait référence à la colonne 'pageId' de la table 'page', 'value' est une clé étrangère et devrait être de même type que 'pageId'.

Au passage, la clé primaire de la table 'config' devrait elle aussi être de type entier. Une bonne clé primaire est anonyme et invariable. Un simple numéro entier est idéal pour ça. En plus, les recherches seront plus rapides sur une colonne entière que sur un varchar.

J'ajoute que pour bénéficier des avantages des contraintes de clés étrangères sous MySQL, vous devriez utiliser le moteur InnoDB plutôt que celui généralement proposé par défaut (MyISAM).

Normalement, les valeurs textuelles se mettent entre apostrophes et non entre guillemets.

Il vaut mieux éviter d'utiliser SELECT * et préférer nommer les colonnes dont on a besoin.

Enfin, la syntaxe normalisée depuis 1992 pour les jointures utilise l'opérateur JOIN. Votre requête gagnerait en clarté en l'écrivant :

Code :

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

1
2
3
4
SELECT p.pageId, lesAutresColonnesVoulues
FROM page p
INNER JOIN config c ON p.pageId = c.value
WHERE c.name = 'homepage'

[Antoine_935]

Si la colonne 'value' de la table 'config' fait référence à la colonne 'pageId' de la table 'page', 'value' est une clé étrangère et devrait être de même type que 'pageId'.

Justement non. La table config devrait contenir différentes valeurs, telles que le nom du site, le footer etc. Aucune clef étrangère n'est donc possible sur cette table.

Au passage, la clé primaire de la table 'config' devrait elle aussi être de type entier. Une bonne clé primaire est anonyme et invariable. Un simple numéro entier est idéal pour ça. En plus, les recherches seront plus rapides sur une colonne entière que sur un varchar.

La recherche évoquée plus haut est la seule et unique que je ferai sur cette table. Et comme la table config ne devra servir qu'à stocker des paires de clefs / valeurs, un identifiant entier n'aurait ici aucun intérêt à mon sens.

Normalement, les valeurs textuelles se mettent entre apostrophes et non entre guillemets.

Bon à savoir, merci


Bon, il ne me reste plus qu'à trouver une alternative pour stocker l'id de la page d'accueil. Si quelqu'un qui passe par là a une idée qui ne comporte pas de notion de fichier ou de champ supplémentaire sur la table page, je suis intéressé

[CinePhil]

Justement non. La table config devrait contenir différentes valeurs, telles que le nom du site, le footer etc. Aucune clef étrangère n'est donc possible sur cette table.

On peut avoir un schéma de la BDD ?
Celui que j'ai déduis du premier message est le MCD suivant :
Page -0,1----Avoir----1,1- Config

La recherche évoquée plus haut est la seule et unique que je ferai sur cette table. Et comme la table config ne devra servir qu'à stocker des paires de clefs / valeurs, un identifiant entier n'aurait ici aucun intérêt à mon sens.

Ces config se rapportent bien à quelque chose ?
Donc une clé étrangère me semble au contraire tout à fait justifiée !

Bon, il ne me reste plus qu'à trouver une alternative pour stocker l'id de la page d'accueil.

L'ID de la page d'accueil (ou des autres pages je suppose) est stockée dans la table Page, ce qui me semble logique.
Si ces pages sont en relation avec d'autres tables de la BDD, l'ID de la page servira de clé étrangère dans les autres tables. C'est de la modélisation rationnelle et normalisée de base de données.

Si quelqu'un qui passe par là a une idée qui ne comporte pas de notion de fichier ou de champ supplémentaire sur la table page, je suis intéressé

Il faudrait pour ça mieux expliquer ton besoin.

[Antoine_935]

Comme tu le proposes, je vais expliquer plus en détails le projet.

C'est un projet de site web (CMS) pour artiste graphique.
Ce site gère des pages organisées en hiérarchie.
Chaque page peut avoir zero, une ou plusieurs images attachées.
Il peut exister plusieurs comptes utilisateur. Chacun de ces utilisateurs a les droits d'administration.
Enfin, il y a pour ce site différentes valeurs définies, telles le nom du site, la notice de pied de page, l'id de la page d'accueil et autres infos nécessaires. Ces informations doivent être facilement modifiables par les administrateurs du site.

Voici le schéma de la DB. Désolé de l'avoir fait à la main, mais je n'ai aucun logiciel correct. C'est un diagramme de Bachmann comme on en fait au cours.
C'est un design très simple, 4 tables. Les champs pageId, pictureId et userId sont bien entendu des entiers. Le champ config.name quant à lui, est un varchar.
Il n'est bien sur pas exclu de rajouter des champs date et auteurs dans la table page, mais ce sera pour plus tard.
page.parent peut bien entendu être NULL, mais j'ai oublié de le noter sur le diagramme.


Comme je le disais tantôt, la table config n'a pas de clef étrangère vers la table page pour la bonne et simple raison qu'elle contient des valeurs de nature plus ou moins variées. Ca peut paraître cochon, mais ça représente plutôt une bonne solution, à mon sens, pour tous ces petits trucs tels la notice de pied de page et le nom du site. Je n'ai jusqu'à présent trouvé aucune alternative valable à ce système. Si quelqu'un a une idée...


Bref, pour l'instant je m'en suis tiré autrement qu'au début: j'ai donc une classe Config qui va chercher les valeurs de la table config et les rend disponible au reste des composants. De là, je prends la valeurs correspondant à la clef "homepage", en fais un entier et injecte ça dans la requête suivante:

Code :

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

SELECT * FROM page WHERE pageId = ?

C'est la meilleure solution que j'aie eue jusqu'à présent...

Tout commentaire est le bienvenu

[CinePhil]

Si je comprends bien, les "config" peuvent se rapporter à une page ou à une autre chose non modélisée dans une entité et une "page" peut avoir plusieurs "config".

Ceci correspond au MCD suivant :
Page -0,n----Avoir----0,1- Config

Les cardinalités (0,n - 0,1) entraînent normalement la même chose que les cardinalités (0,n - 0,n) : une table associative.

Il a été maintes fois expliqué ici qu'une clé primaire de type entier est meilleure. Je te conseille donc d'adopter ce principe aussi pour la table "config".

Ce qui donnerait les tables :
Page (pageID, title, contents, parent)
Config (configID, name, value)
Page_Config (pageID, ConfigID)

On pourrait même déplacer la "value" dans la table associative, ce qui permettrait de revenir à un schéma plus classique :
Page -0,n----Avoir----0,n- Config

Et les tables :
Page (pageID, title, contents, parent)
Config (configID, name)
Page_Config (pageID, ConfigID, value)

Ainsi, la "notice de pied de page" pourrait être différente pour toutes les pages par exemple.

[Antoine_935]

une "page" peut avoir plusieurs "config".

Non, les pages ne se préoccuppent absolument pas de la table config. Rien, aucune relation. config ne dénote pas la configuration d'une page (pourquoi la mettrais-je hors de la table page ?). Elle dénote la configuration du site web.
La seule chose, c'est que je dois bien avoir une page d'accueil définie quelque part, histoire de savoir où aller lorsqu'un utilisateur arrive sur le site.

Le meilleur endroit que j'aie trouvé jusqu'à présent por stocker l'id de la page d'accueil, c'est cette table config. Il n'existe aucune autre relation entre page et config.

Il a été maintes fois expliqué ici qu'une clé primaire de type entier est meilleure. Je te conseille donc d'adopter ce principe aussi pour la table "config".

Je n'aurais ici aucune utilité d'un entier pusqu'il s'agit de couple clef/valeurs qui n'ont de sens que par la signification de leur clef. Or, un chiffre ne signifie pas grand chose, c'est pourquoi je mets un varchar.
Comment pourrais-je savoir que la config dont la clef est "1" correspond au nom du site ? C'est nettement plus clair de prendre pour clef "nom du site".

Ainsi, la "notice de pied de page" pourrait être différente pour toutes les pages par exemple.

Pour faire cela, il serait nettement plus simple de mettre la notice de pied de page directement dans la table page.


Je le répète, la table config n'a rien à voir avec la table page. Il se trouve, par contre et par hasard, que je dois stocker quelle est ma page d'accueil quelque part. Ma question porte donc là dessus: existe-t-il une meilleure manière de stocker l'id de ma page d'accueil ?

[CinePhil]

OK alors je reviens à la question et à la requête de base.
Pour faire ça proprement, il faut convertir explicitement la "value" en entier pour la faire correspondre avec l'id de la page :

Code :

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

1
2
3
4
SELECT p.pageId, lesAutresColonnesVoulues
FROM page p
INNER JOIN config c ON p.pageId = CAST(c.value AS INTEGER)
WHERE c.name = 'homepage'

A noter que ceci ne fonctionne pas sous MySQL car il demande en fait la précision SIGNED ou UNSIGNED à la place de INTEGER :

Code :

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

1
2
3
4
SELECT p.pageId, lesAutresColonnesVoulues
FROM page p
INNER JOIN config c ON p.pageId = CAST(c.value AS UNSIGNED)
WHERE c.name = 'homepage'

[Antoine_935]

Ah, j'avais bien trouvé la piste des cast, mais je n'arrivais pas à le faire fonctionner avec mon... MySQL.

Merci pour cette solution