Discussion :

[bronon]

Bonjour à tous,
Ce matin je bute sur un problème que je n’ai jamais eu à résoudre auparavant.
Je cherche à sélectionner une ou plusieurs colonnes avec une contrainte where sur l’index.
Expliqué autrement :

Code :

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

SELECT *  from table WHERE (table.COLUMN_NAME Primary key) = 34

Si qq peut m’indiquer une piste, je lui en saurais gré !!!
D’avance merci

PS : Je reprends une vieille base dont les primary key varient sur chaque table ??!!

[escartefigue]

Bonjour,

Je ne vois pas où est la difficulté, ou alors je n'ai pas compris votre besoin

Soit la table T1, dotée des colonnes Col1, Col2 et Col3

Si la clef primaire est Col1, alors la requête est tout simplement

Code :

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

1
2
3
4
select Col1
     , Col2
     , Col3
where Col1=34

Vu que pour la PK, l'index est créé automatiquement, vous êtes certains d'avoir au moins un index satisfaisant le prédicat de filtrage, il n'est toutefois pas certain que ce soit l'index de la PK qui sera choisi par l'optimiseur. Mais ça n'a aucune importance, fonctionnellement, le résultat sera celui souhaité

[isabelle.letrong]

Bonjour bronon,

Je reprends une vieille base dont les primary key varient sur chaque table ??!!

je ne vois pas trop ce que vous voulez dire par 'les primary key varient sur chaque table'.
Effectivement chaque table a sa propre clé primaire qui peut être un entier technique, ou encore l'union de colonnes 'porteuses de sens'. C'est une question de (bonne) conception du modèle...
Pourriez-vous préciser votre difficulté ?

[bronon]

Merci pour vos retours,
Je précise mon problème comme vous le souhaitiez.
Aujourd’hui je fais la requête suivante :

Code :

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

SELECT variable FROM table1 WHERE id = valeur

Le seul problème que j’ai est que l’id est la clé primaire de la table mais que cette clé primaire change de nom souvent en fonction de la table, par exemple :

Code :

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

1
2
3
4
 table 1 clé primaire id
 table 2 clé primaire idClient
 table 3 clé primaire idSoc
 table 4 clé primaire email

Etc.
Ceci oblige à une lourde programmation puisqu’il faut indiquer en clair l’id de référence.
Je voudrais dans la clause WHERE définir l’id par la clé primaire de la table en question
J’ai retourné la question un peu dans tous les sens notamment en utilisant

Code :

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

INFORMATION_SCHEMA.KEY_COLUMN_USAGE

sans succès !
Ma question est comment faire ?

J’espère avoir été + clair
D’avance merci

[isabelle.letrong]

bronon,

En s'appuyant sur le catalogue MySQL on peut tout faire, notamment allez chercher des noms de colonnes, de clés, puis construire des requêtes dynamiques mais, vraiment, je ne comprends pas le sens de ce que vous cherchez à faire.
Par ailleurs, une clé primaire peut être composite et donc répartie sur plusieurs colonnes d'une table , ce qui implique dans ce cas que la restriction (clause WHERE) doit nommer plusieurs colonnes. Est-ce que tout ceci a bien du sens ?

Peut-être une explication sur la finalité du développement en cours nous éclairerait.

[bronon]

Je cherche simplement (!) à faire si C possible

Code :

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

SELECT variable FROM table1 WHERE clé primaire de la table1 = valeur

[escartefigue]

Comme indiqué par Isabelle, il est bien sur possible d'exploiter le catalogue pour connaitre le nom de la ou des colonnes PK de chacune des tables, mais pour autant, les colonnes de la clause select ne peuvent pas être les mêmes. Du coup l'intérêt semble plus que limité...
Sans rentrer dans le langage SQL ni autre considération technique, quel est le besoin fonctionnel ?

[bronon]

En ce moment j’effectue ses requêtes en deux fois :
Requête un pour déterminer quelle est la colonne avec la clé primaire que je mets sous forme de variables PHP

Code :

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

1
2
3
4
$sql= "SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = '".$Table."' AND CONSTRAINT_NAME = 'PRIMARY'";
$result = $pdo->query($sql);
$Primary = $result->fetch();
echo 'Primary : '.$Primary['COLUMN_NAME'];

Requête deux pour déterminer quelle est la valeur de la variable dans la table donnée

Code :

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

1
2
 
$sql = "UPDATE ".$Table." SET ".$rubrique."='".$valeur."' WHERE ".$Primary['COLUMN_NAME']."=".$Cookie;

Je veux faire ceci en 1 seule requête.
Est-ce possible si oui comment ?

[CinePhil]

Mais POURQUOI vouloir faire ça ?

Si vous avez travaillé correctement, vous avez conçu et développé une base de données relationnelle dans laquelle les tables ont un nom signifiant (tel que 'te_personne_prs' ou 't_projet' ou 'adresse'...) et dans votre application des fonctions d'interrogation ou de mise à jour des tables selon les besoins spécifiques à chaque table. Si c'est dans une classe d'accès aux données spécifiques de la table c'est encore mieux. Dès lors, votre classe Personne va travailler avec la table des personnes et connaît déjà sa clé primaire prs_id ou id_personne ou personne_id... L'abstraction du nom de la table et de ses colonnes ne sert à rien ; ça obscurcit le code.

[isabelle.letrong]

vade retro du PHP... !!

Donc, si je comprends bien la valeur de la clé primaire est la même ($cookie) pour toutes les tables que vous ciblez. Je suppose donc que toutes ces tables héritent de la même clé primaire (qui porte un nom spécifique à chaque table), clé primaire qui est donc également foreign key d'un objet supérieur dans la hiérarchie de l'héritage...

C'est bien cela ?

[escartefigue]

Ce mode de fonctionnement va à l'encontre des règles d'urbanisme applicatif, c'est du SQL dynamique qui peut s'appliquer sur la totalité des tables de la base de données

Je serai curieux de savoir comment vous alimentez le nom de la colonne dans la variable $rubrique

Et encore une fois, quel est le besoin fonctionnel ?

[bronon]

Mais POURQUOI vouloir faire ça ?

Si vous avez travaillé correctement, vous avez conçu et développé une base de données relationnelle dans laquelle les tables ont un nom signifiant (tel que 'te_personne_prs' ou 't_projet' ou 'adresse'...) et dans votre application des fonctions d'interrogation ou de mise à jour des tables selon les besoins spécifiques à chaque table. Si c'est dans une classe d'accès aux données spécifiques de la table c'est encore mieux. Dès lors, votre classe Personne va travailler avec la table des personnes et connaît déjà sa clé primaire prs_id ou id_personne ou personne_id... L'abstraction du nom de la table et de ses colonnes ne sert à rien ; ça obscurcit le code.

Malheureusement cette BD a été conçu il y a au moins 15 ans et fil du temps chacun à apporter ses modifications, ses erreurs… J'hérite du baby pour ajouter qq modules pour lesquels j'ai besoin de ces requêtes donc voilà la raison de mon « mauvais travail »

[bronon]

Ce mode de fonctionnement va à l'encontre des règles d'urbanisme applicatif, c'est du SQL dynamique qui peut s'appliquer sur la totalité des tables de la base de données

Je serai curieux de savoir comment vous alimentez le nom de la colonne dans la variable $rubrique

Et encore une fois, quel est le besoin fonctionnel ?

Je serai curieux de savoir comment vous alimentez le nom de la colonne dans la variable $rubrique

Par

Code :

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

$_POST['rubrique']

venant de la requête ajax en amont !!!

[bronon]

vade retro du PHP... !!

Donc, si je comprends bien la valeur de la clé primaire est la même ($cookie) pour toutes les tables que vous ciblez. Je suppose donc que toutes ces tables héritent de la même clé primaire (qui porte un nom spécifique à chaque table), clé primaire qui est donc également foreign key d'un objet supérieur dans la hiérarchie de l'héritage...

C'est bien cela ?

Non

Code :

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

$cookie

vient la requête ajax en post

[isabelle.letrong]

J'hérite du baby pour ajouter qq modules pour lesquels j'ai besoin de ces requêtes »

Désolée, mais nous sommes au moins trois à ne pas comprendre pourquoi "j'ai besoin de ces requêtes".
La vrai question est donc : en avez-vous besoin ? Ce qui est perturbant et incompréhensible en premier abord c'est que vous êtes prêt à monter une usine à gaz pour éviter de nommer explicitement les colonnes telles que définies dans le DDL des tables. En faisant cela on a également l’impression que vous souhaitez êtes contrevenant par rapport à un point fondamental du relationnel : définir ce que l'on veut atteindre sans jamais définir comment l'atteindre.

Enfin pour reprendre votre liste donnée en exemple :

Code :

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

1
2
3
4
table 1 clé primaire id
 table 2 clé primaire idClient
 table 3 clé primaire idSoc
 table 4 clé primaire email

Cette liste concerne donc des objets conceptuellement éloignés (Client, Société, email,.... et nous sommes bien d'accord ils ne sont pas une spécialisation d'un seul et même acteur, on ne parle pas ici de la Société du Client et de l'Email du Client...). Supposons que, comme vous le souhaitez, les clés primaires de chacun de ces objets ce nomment 'id'. En quoi cela vous simplifierait-il la vie ?

[Sebwar]

nous sommes au moins trois à ne pas comprendre pourquoi "j'ai besoin de ces requêtes"

+1 Je ne comprends pas non plus..

[CinePhil]

Malheureusement cette BD a été conçu il y a au moins 15 ans et fil du temps chacun à apporter ses modifications, ses erreurs… J'hérite du baby pour ajouter qq modules

Donc, vous cherchez à mettre en oeuvre une solution complexe pour démêler un plat de spaghetti asséché par le temps.

Si j'avais à reprendre une application et une BDD mal foutue, je choisirais entre :
1) Reconcevoir et redévelopper tout correctement.
2) Essayer de faire au moins mon bout de code correctement avec une classe de connexion à la BDD et des classes modèles d'accès aux données qui contiendrait des requêtes utilisant les noms des tables et des colonnes en clair.
3) Faire au plus vite et au plus simple possible en ajoutant mon bout de code sans rien changer au reste.

Le choix 3 ne me ferait pas chercher une solution complexe à l'aide de variables pour nommer des choses que je connais déjà. Je me contenterais de faire du code (un peu pourri) à l'ancienne de ce genre :

Code PHP :

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

1
2
3
4
5
6
$sql = "SELECT des, colonnes
	FROM la_table
	WHERE id = intval($id_cherche)
";
 
$result = mysql_query($sql);

[Artemus24]

Salut bronon.

Pour répondre à votre problème, personne ne procède ainsi.

Mais au préalable, vous devez connaitre votre dictionnaire des données.
C'est-à-dire le nom de toutes les colonnes de toutes vos tables, sachant qui est clef primaire, qui est clef étrangère, et qui est informationnelle.

Ensuite, si votre dictionnaire est bien conçu, un nom de colonne désignant un usage particulier, aura le même nom dans toute la base de données.
J'ai pris l'habitude de nommer mes clefs primaire auto incrémenté par "id" pour identifiant, même si elle concerne des tables différentes.
Quand je fais référence à ces clefs primaire, au travers des clefs étrangère, j'indique "clef" ou "id" suivi du nom de la table.
Par exemple "clef_personnel" pour la clef étrangère qui va pointer sur la colonne "id" (donc la clef primaire) de la table "personnel".

Si vous désirez fusionner vos deux requêtes, dans ce cas, vous devez la construire.
Or je constate que c'est ce que vous faites déjà en php.

Il y a un léger problème avec votre requête car elle ne traite que les cas où la clef primaire est constituée que d'une seule colonne.

Malheureusement cette BD a été conçu il y a au moins 15 ans

Ce n'est pas une excuse.

et fil du temps chacun à apporter ses modifications, ses erreurs…

Si vous considérez cela comme des erreurs, pourquoi ne pas les corriger par vous-même ?

Désolée, mais nous sommes au moins trois à ne pas comprendre pourquoi "j'ai besoin de ces requêtes".

Cinq, après Sebwar, car je rentre aussi dans la danse.

Escartefigue me reprendra, mais vous désirez utiliser le "meta language" de mysql pour faire du sql dynamique.

Donc en partant de votre idée en en faisant cela en mysql :

Code :

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

SELECT *  from table WHERE (table.COLUMN_NAME Primary key) = 34

Pour construire votre requête, je propose une procédure stockée, que voici :

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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
--------------
SET AUTOCOMMIT = 0
--------------
 
--------------
START TRANSACTION
--------------
 
--------------
DROP PROCEDURE IF EXISTS `build`
--------------
 
--------------
CREATE PROCEDURE `build`
(
  in _base   varchar(255),
  in _table  varchar(255),
  in _col    varchar(255),
  in _where  varchar(255)
)
DETERMINISTIC
NO SQL
BEGIN
DECLARE _fin INTEGER DEFAULT 1;
DECLARE _z   varchar(255);
DECLARE _tab CURSOR FOR SELECT  concat(' where (', group_concat(column_name order by ordinal_position separator ','),') = ')
                          from  information_schema.key_column_usage
                         where  table_schema    =  _base
                           and  table_name      =  _table
                           and  constraint_name = 'primary'
                      order by  table_schema, table_name;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET _fin = 0;
 
OPEN  _tab;
FETCH _tab INTO _z;
CLOSE _tab;
 
set @req = concat("select ",_col," from ",_base,'.',_table,_z,_where);
 
select @req;
 
PREPARE            stmt1 FROM @req;
EXECUTE            stmt1;
DEALLOCATE PREPARE stmt1;
 
END
--------------
 
--------------
call `build` ('base','test','*','3')
--------------
 
+----------------------------------------+
| @req                                   |
+----------------------------------------+
| select * from base.test where (id) = 3 |
+----------------------------------------+
+----+-------+
| id | val   |
+----+-------+
|  3 | trois |
+----+-------+
--------------
COMMIT
--------------
 
--------------
SET AUTOCOMMIT = 1
--------------
 
Appuyez sur une touche pour continuer...

Je me suis amusé à créer cette procédure stockée pour vous montrer que l'on automatiser la construction d'une requête dynamique.

@+

[bronon]

Merci pour ta réponse que je dois regarder avec précision car je suis très peu familier avec cette manière de « scripter »

Pour finaliser une partie de mon problème consistant à, pour l'update d'une colonne, récupérer le nom de la table ainsi que la primary key de la table :

Code :

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

1
2
 
SELECT ic.TABLE_NAME AS nomTable, ic.COLUMN_NAME AS nomCol, icu.COLUMN_NAME AS ident FROM INFORMATION_SCHEMA.COLUMNS ic RIGHT JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE icu ON icu.CONSTRAINT_NAME = 'primary' AND icu.TABLE_NAME = ic.TABLE_NAME AND icu.table_schema = 'xxxxxxx' WHERE ic.COLUMN_NAME = 'yyyyyyy' AND ic.table_schema = '"$rubrique"'

Ce qui a l'avantage de faire « le job » mais très lentement

Maintenant j'aimerai inclure cette requête dans celle de l'update pour n'avoir qu'une requête au total mais là je pense que j'approche la mission impossible !

[Artemus24]

Salut Salut bronon.

Comme je l'ai dit précédemment, vous devez construire votre requête.
Quand vous récupérez vos noms de colonnes, ce sont des chaînes de caractères et non des colonnes de tables.
C'est ce que je fais dans le curseur de la procédure stockée.
Je récupère toutes les colonnes faisant partie de la clef primaire.
La plupart du temps, cela va se résumer à une colonne.
Mais si vous en avez deux ou plus, la clause where va s'écrire ainsi :

Code :

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

where (col1,col2,col3) = (4, 12, 8);

C'est la raison des parenthèses autour de la colonne "id" dans mon exemple.

Et pour mettre en forme ce genre de traitement, rien de tel qu'une procédure stockée.

@+