Code sql pour ordonner une table

Bonjour,
Je gère une table avec des "codes opération" représentant le numéro de toutes les opérations accessibles aux utilisateurs (créations (utilisateurs, rubriques, activités...), suppression, éditions diverses etc.)
Avec PhPmyadmin, je peux ordonner la table après chaque insertion afin que les N° d'opération restent dans leur ordre logique, en cliquant sur "ordonner la table"
Malheureusement, le code de cette requête n'est pas indiqué en clair alors que je voudrais l'intégrer dans mon application afin de réordonner la table elle-même lors de chaque nouvel ajout d'une opération (au fur et à mesure que l'application évoluera, le nombre d'opérations accessibles aux utilisateurs ira croissant et j'envisage une transaction de saisie spécifique "création d'une opération".
Je n'ai pas trouvé d'explication sur le forum, ni sur d'autres, d'ailleurs car on me renvoie systématiquement vers "order by" ce qui ne correspond pas à ce que je cherche puisque je veux reclasser la table elle-même et non, simplement, organiser les sélections.
Je suis preneur de toute info...
Merci et bon réveillon à toutes et tous.

Bonjour,
Question bête: pourquoi veux tu "ordonner" la table ?
En quoi l'ordre des lignes dans la table a une quelconque importance ?
Il me semble d'ailleurs

Tout le monde te renvoie vers 'ORDER BY", car au final seul l'ordre des lignes dans le résultat d'une requête me semble important.
Mais visiblement tu n'est pas de cet avis.
Donc plutôt que de faire "comme tout le mode", je cherche quel est le besoin derrière cette demande.

Quoi qu'il en soit, tu peux le faire avec un ALTER TABLE.

Tatayo.

Salut à tous.

Bonne année, bonne santé, mes meilleurs vœux pour 2021. :D

Citation:

---

Envoyé par Tatayo

Question bête: pourquoi veux tu "ordonner" la table ?

---

Il n'y a rien de bête dans cette question.

Je dirais même que si NovembreZoulou constate qu'il y a un problème avec sa table, c'est que sa base doit contenir d'autres problèmes, comme celui de la modélisation.

L'ordre de sortie des lignes d'une table quand on fait un simple "select * from ma_table" dépendent des index.
S'il n'y a pas d'index et de surcroit pas de primary key, l'ordre de sortie dépend de l'ordre de stockage (ou d'entrée).
Je peux comprendre qu'un "alter table ma_table order by col1, col2" puisse remettre de l'ordre dans la table.
Mais dans ce cas, pourquoi ne pas utiliser une clef primaire sur ls col1 et col2 ?

A vrai dire, il nous faudrait le "describe ma_table" pour mieux comprendre la problématique.

@+

NON @Artemus24.
Discuter de l'ordre d'une table est la preuve évidente que vous n'avez rien compris à la théorie des SGBD relationnels.
Par définition une table n'est pas ordonnée, quels que soient ses index ou sa clé primaire.
Si un semblant d'ordre apparait lors d'une requête SELECT sans clause ORDER BY, ce n'est qu'un effet de bord de l'implémentation par le SGBD dont la pérennité ne peut être assurée.

Une table n'est jamais "ordonnée" en elle-même : on ordonne les données avec un ORDER BY.

Toujours.

Merci de vos réponses
Je m'occupe de l'asso de retraités de ma boite (+-9000 adhérents) gérée par des bénévoles et je crée (ou essaye de créer) un outil de gestion...
Une centaine de membres ont accès à un espace spécifique permettant la réalisation d'opérations : administration, gestion des adhérents, gestion comptable, gestion des régions, gestion du journal (envoyé à 9000 ex), etc.
Chaque opération est référencée dans la table "codeoperations" de 0.01 à n.nn, O étant la famille "administration", 1 la gestion des adhérents, 2 les opérations comptables... chaque opération prenant un n° dans sa famille (1.01 création, 1.02, modification, 1.03 désactivation, etc.
Ces codes opérations sont repris comme titres des colonnes de la table "habilitationsmembres", les rangs de cette table étant les adhérents habilités à intervenir.
S'il m'est demandé d'ajouter une opération (ajouter 2.10 après 2.09 par exemple) ce champs vient en dernière position dans la table après, bien sûr, les opérations 3.01, 3.02 etc. et un select me renvoie les habilitations dans le même ordre alors que je souhaite que 2.10 soit classé après 2.09 mais avant le 3.01 dans le sélect. Un order by me classe (enfin si j'ai bien tout compris) les rangs sur une ou plusieurs de ces colonnes alors que, dans mon cas, je souhaite récupérer les habilitations de l'intéressé classées selon l'ordre de ces colonnes elles-mêmes et non de leur contenu...
Merci de vos éclaircissements
NZ

Si je comprends bien les habilitations sont lues avec un "SELECT * " et la manipulation a pour objet de présenter les colonnes dans l'ordre "alphabétique" plutôt que dans l'ordre de création ?
Comme l'a recommandé Tatayo, on utilise ALTER TABLE pour repositionner une colonne dans la table.
Voici un article sur ALTER TABLE ciblé sur l'ordre des colonnes.

Pour l'intégrer dans le code de l'application, il faut aussi lire le catalogue de la base de données pour connaître la liste des colonnes et identifier après laquelle on place la petite nouvelle.
Mais quitte à faire cela, autant l'identifier avant la création et insérer directement la colonne au bon endroit, non ?

Exemple de syntaxe pour l'ajout de colonne bien positionné :

Code:

---

1 2 3 4 5

ALTER TABLE `habilitationsmembres` ADD COLUMN ( `7.01` tinyint(4) NOT NULL DEFAULT 0 ) AFTER `6.11`;

---

Est-ce que tu peux nous donner la structure de tes tables ?
Comme je te vois parler de tri "selon l'ordre des colonnes et non leur contenu", j'ai comme l'impression qu'il y a un loup dans la modélisation de ta base de données.

Tatayo.

Citation:

---

Envoyé par novembrezoulou

...
Avec PhPmyadmin, je peux ordonner la table après chaque insertion afin que les N° d'opération restent dans leur ordre logique, en cliquant sur "ordonner la table"...

---

Cela n'est absolument pas possible. Par définition les lignes d'une table n'ont aucun ordre de rangement dans la base. C'est une erreur courante de penser cela. Une table n'est pas un tableau d'un tableur !
A me lire :
https://sqlpro.developpez.com/cours/sqlaz/erreurs/#L5

A +

Citation:

---

Envoyé par SQLpro

Cela n'est absolument pas possible. Par définition les lignes d'une table n'ont aucun ordre de rangement dans la base.

---

Si j'ai bien compris, il ne s'agit pas de trier les enregistrements mais d'ordonner les colonnes.
La table "habilitationsmembres" contient un grand nombre de colonnes "1.01", "1.02", etc. et des colonnes supplémentaires sont créées à la volée, chacune représentant une habilitation. C'est à ce moment-là que les concepteurs de bases de données relationnelles s'évanouissent d'horreur ;) Parce que, effectivement :

Citation:

---

Envoyé par SQLpro

Une table n'est pas un tableau d'un tableur !

---

et on si on ajoute des colonnes régulièrement, ce n'est pas bon signe.

Ce n'est jamais vain d'améliorer la modélisation d'une base de données, a fortiori si les habilitations évoluent régulièrement : cela vaut sûrement la peine de modifier le schéma de la base en créant une relation entre les membres et les habilitations.
Alors on pourrait utiliser gentiment ORDER BY, pour le coup.

Citation:

---

Envoyé par Paraffine

Si j'ai bien compris, il ne s'agit pas de trier les enregistrements mais d'ordonner les colonnes.
La table "habilitationsmembres" contient un grand nombre de colonnes "1.01", "1.02", etc. et des colonnes supplémentaires sont créées à la volée, chacune représentant une habilitation. C'est à ce moment-là que les concepteurs de bases de données relationnelles s'évanouissent d'horreur ;) Parce que, effectivement : et on si on ajoute des colonnes régulièrement, ce n'est pas bon signe.

Ce n'est jamais vain d'améliorer la modélisation d'une base de données, a fortiori si les habilitations évoluent régulièrement : cela vaut sûrement la peine de modifier le schéma de la base en créant une relation entre les membres et les habilitations.
Alors on pourrait utiliser gentiment ORDER BY, pour le coup.

---

En fait, je n'ai pas de "modélisation" car... je ne sais pas en faire ! comme je l'ai écrit, je ne suis pas un pro et je ne sais pas utiliser le "concepteur" de phpMyAdmin.
J'ai une base (portant le nom de l'asso) et tout plein de tables. Je suis bien conscient que ça ferait hurler de rire (ou d'horreur) un informaticien mais mon truc a le mérite de fonctionner et de suffire à mes utilisateurs (des retraités, comme moi, ayant pour certains largement passé les 70 / 75 ans...).
Ma table "codesoperations dispose de 3 colonnes : codeopenum (index unique - varchar(6)), codeopelibelle (text), codeopeactif (tinyint) ce dernier permettant de désactiver temporairement une opération [clôture de l'exercice comptable par exemple].
La table habuilitationsmembres comprend 29 colonnes : aminum (index unique, int(11)), actif (tinyint(1), fonctionope (int(11)) qui gère la fonction de l'utilisateur, visibilite (tinyint(1)) qui permet un accès national ou régional aux informations, puis 25 colonnes tinyint nommées de 0.01 à 3.01 en fonction de l'opération et de valeur 0 ou 1 selon que l'utilisateur est habilité ou non. le nom de ces colonne correspond au "codeopenum" de la table précédente. J'avoue que les jointures sont quelque chose que je ne maitrise qu'assez peu actuellement (mais j'ai bon espoir !)
L'idée était, effectivement que le select * from habilitationsmembres where aminum= (n° de l'utilisateur) me retourne les habilitations de l'intéressé classé par ordre croissant de n° d'opérations.
le problème est que de nouvelles opérations peuvent, un jour, venir s'ajouter à celles existantes et je voulais donc un écran de "création d'opération" mettant à jour la table codeoperations (là pas de problème de reclasser quoi que ce soi) et intègre la nouvelle opération dans la table habilitation, en la mettant à 0 pour tous...

Merci d'avoir pris le temps de voir ce problème
Je vais utiliser ALTER TABLE, mais je pensais qu'il existait un moyen de reclasser les champs avec celui ajouté (en fin de table) sans me préoccuper de l'endroit d'insertion une fois cette insertion réalisée.

Salut à tous.

Bonne année, bonne santé à toutes et à tous, mes meilleurs vœux pour l'année 2021.

@ al1_24 : je crois que vous n'avez rien compris de la question posée par novembrezoulou.
Voici la question posée :

Citation:

---

Envoyé par NovembreZoulou

je peux ordonner la table après chaque insertion afin que les N° d'opération restent dans leur ordre logique,

---

Traduction : il veut un ordre apparent et non un ordre de stockage des lignes dans la table.
Il y a une chose dont vous ne savez pas, d'après vos remarques. Les lignes sont rangées dans l'ordre d'arrivé dans la table.

Citation:

---

Envoyé par Al1_24

Si un semblant d'ordre apparait lors d'une requête SELECT sans clause ORDER BY, ce n'est qu'un effet de bord de l'implémentation par le SGBD dont la pérennité ne peut être assurée.

---

Il n'y a aucun effet de bord dans l'ordre apparant d'une requête SELECT.
Il suffit de connaitre le comportement de MySql pour prévoir l'ordre apparent des lignes à l'affichage.

Voici des exemples où j'utilise à chaque fois la requête : "select * from `test`".

1) s'il n'y a pas de primary key, ni d'index, l'ordre apparent ou si vous préférez celui à l'affichage, est celui de l'arrivée dans les insertions. Voici un exemple :

Code:

---

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

-------------- START TRANSACTION --------------   -------------- set session collation_connection = "latin1_general_ci" --------------   -------------- DROP DATABASE IF EXISTS `base` --------------   -------------- CREATE DATABASE IF NOT EXISTS `base` DEFAULT CHARACTER SET `latin1` DEFAULT COLLATE `latin1_general_ci` --------------   -------------- DROP TABLE IF EXISTS `test` --------------   -------------- CREATE TABLE `test` ( `mess` varchar(25) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED --------------   -------------- insert into `test` (`mess`) values ('sept'), ('deux'), ('dix'), ('quatre'), ('un'), ('huit'), ('six'), ('trois'), ('cinq'), ('neuf') --------------   -------------- select * from `test` --------------   +--------+ | mess | +--------+ | sept | | deux | | dix | | quatre | | un | | huit | | six | | trois | | cinq | | neuf | +--------+ -------------- COMMIT --------------   Appuyez sur une touche pour continuer...

---

Comme on le constate, l'ordre apparent est celui de l'arrivé dans la table.
Ou si vous préférez, c'est l'odre FIFO, le premier arrivée est le premier à sortir (à l'affichage).

2) si maintenant j'utilise une primary key, l'ordre apparent est celui de la primary key.

Code:

---

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

-------------- START TRANSACTION --------------   -------------- set session collation_connection = "latin1_general_ci" --------------   -------------- DROP DATABASE IF EXISTS `base` --------------   -------------- CREATE DATABASE IF NOT EXISTS `base` DEFAULT CHARACTER SET `latin1` DEFAULT COLLATE `latin1_general_ci` --------------   -------------- DROP TABLE IF EXISTS `test` --------------   -------------- CREATE TABLE `test` ( `id` integer unsigned NOT NULL primary key, `mess` varchar(25) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED --------------   -------------- insert into `test` (`id`,`mess`) values (3,'sept'), (8,'deux'), (2,'dix'), (9,'quatre'), (10,'un'), (4,'huit'), (5,'six'), (6,'trois'), (1,'cinq'), (7,'neuf') --------------   -------------- select * from `test` --------------   +----+--------+ | id | mess | +----+--------+ | 1 | cinq | | 2 | dix | | 3 | sept | | 4 | huit | | 5 | six | | 6 | trois | | 7 | neuf | | 8 | deux | | 9 | quatre | | 10 | un | +----+--------+ -------------- COMMIT --------------   Appuyez sur une touche pour continuer...

---

J'ai fait exprès d'insérer ls lignes dans un ordre quelconque.
Comme on peut le voir à l'affichage, l'ordre apparent est bien celui de la colonne `id`, c'est-à-dire la primary key.

3) on peut aussi utiliser un index sur la colonne 'mess'. La colonne sera triée alphabétiquement :

Code:

---

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

-------------- START TRANSACTION --------------   -------------- set session collation_connection = "latin1_general_ci" --------------   -------------- DROP DATABASE IF EXISTS `base` --------------   -------------- CREATE DATABASE IF NOT EXISTS `base` DEFAULT CHARACTER SET `latin1` DEFAULT COLLATE `latin1_general_ci` --------------   -------------- DROP TABLE IF EXISTS `test` --------------   -------------- CREATE TABLE `test` ( `id` integer unsigned NOT NULL primary key, `mess` varchar(25) NOT NULL, index `idx` (`mess`) ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED --------------   -------------- insert into `test` (`id`,`mess`) values (3,'sept'), (8,'deux'), (2,'dix'), (9,'quatre'), (10,'un'), (4,'huit'), (5,'six'), (6,'trois'), (1,'cinq'), (7,'neuf') --------------   -------------- select * from `test` --------------   +----+--------+ | id | mess | +----+--------+ | 1 | cinq | | 8 | deux | | 2 | dix | | 4 | huit | | 7 | neuf | | 9 | quatre | | 3 | sept | | 5 | six | | 6 | trois | | 10 | un | +----+--------+ -------------- COMMIT --------------   Appuyez sur une touche pour continuer...

---

La colonne `mess` est triée alphabétiquement, comme on peut le voir.

Quant il y a une clef primaire et un seul index, l'ordre[u]apparent|/u] est donnée par l'index.

Al1_24, avant de réagir promptement comme vous le faites à mon encontre, commencez par lire correctement mes remarques.
Comme vous pouvez le constater, je suis bien conforme à ce que j'ai dit !
Dois-je comprendre que vous ne savez pas comment se comporte MySql ?

@ NovembreZoulou : vous avez raison, c'est bien un "order by" que vous devez utiliser pour ordonner vos lignes selon tel ou tel critères.
Il existe des solutions qui ne font que surcharger la base de données sans changer la façon, dont mysql travaille.
Autrement dit, on s'en fout de l'ordre de stockage de vos lignes car cela n'a aucune importance sur le résultat final que vous recherchez.

Citation:

---

Envoyé par NovembreZoulou

S'il m'est demandé d'ajouter une opération (ajouter 2.10 après 2.09 par exemple) ce champs vient en dernière position dans la table après, bien sûr, les opérations 3.01, 3.02 etc. et un select me renvoie les habilitations dans le même ordre ...

---

Oui, c'est le comportement normal de MySql si vous ne précisez pas l'ordre apparent que vous désirez à l'affichage.

Citation:

---

Envoyé par NovembreZoulou

... alors que je souhaite que 2.10 soit classé après 2.09 mais avant le 3.01 dans le sélect.

---

Qu'est-ce qui vous empêche de mettre un "ordre by" dans votre select ?

Citation:

---

Envoyé par NovembreZoulou

Un order by me classe (enfin si j'ai bien tout compris) les rangs sur une ou plusieurs de ces colonnes

---

Voici c'est bien cela.
Voici un exemple, où l'avant dernier select vous donne l'ordre [u]apparent|/u] qui vous pose problème.
Et la dernière requête qui vous donne l'ordre [u]apparent|/u] que vous désirez obtenir.

Code:

---

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 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87

-------------- START TRANSACTION --------------   -------------- set session collation_connection = "latin1_general_ci" --------------   -------------- DROP DATABASE IF EXISTS `base` --------------   -------------- CREATE DATABASE IF NOT EXISTS `base` DEFAULT CHARACTER SET `latin1` DEFAULT COLLATE `latin1_general_ci` --------------   -------------- DROP TABLE IF EXISTS `test` --------------   -------------- CREATE TABLE `test` ( `id` integer unsigned NOT NULL primary key, `mess` varchar(25) NOT NULL, `val` smallint unsigned NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED --------------   -------------- insert into `test` (`id`,`mess`,`val`) values (3,'sept',7), (8,'deux',2), (2,'dix',10), (9,'quatre',4), (10,'un',1), (4,'huit',8), (5,'six',6), (6,'trois',3), (1,'cinq',5), (7,'neuf',9) --------------   -------------- select * from `test` --------------   +----+--------+-----+ | id | mess | val | +----+--------+-----+ | 1 | cinq | 5 | | 2 | dix | 10 | | 3 | sept | 7 | | 4 | huit | 8 | | 5 | six | 6 | | 6 | trois | 3 | | 7 | neuf | 9 | | 8 | deux | 2 | | 9 | quatre | 4 | | 10 | un | 1 | +----+--------+-----+ -------------- select * from `test` order by `val` --------------   +----+--------+-----+ | id | mess | val | +----+--------+-----+ | 10 | un | 1 | | 8 | deux | 2 | | 6 | trois | 3 | | 9 | quatre | 4 | | 1 | cinq | 5 | | 5 | six | 6 | | 3 | sept | 7 | | 4 | huit | 8 | | 7 | neuf | 9 | | 2 | dix | 10 | +----+--------+-----+ -------------- COMMIT --------------   Appuyez sur une touche pour continuer...

---

Citation:

---

Envoyé par NovembreZoulou

dans mon cas, je souhaite récupérer les habilitations de l'intéressé classées selon l'ordre de ces colonnes elles-mêmes et non de leur contenu...

---

Avez-vous une table qui contient le libellé de ces habilitations et une colonne servant de clef à cette table ?
Je vous donne un exemple où la table "nombre" contient le libellé que vous désirez afficher.
La table "test" possède une clef étrangère ("val") qui va faire référence à la clef primaire "id" de la table "nombre".
Voici l'exemple :

Code:

---

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 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112

-------------- START TRANSACTION --------------   -------------- set session collation_connection = "latin1_general_ci" --------------   -------------- DROP DATABASE IF EXISTS `base` --------------   -------------- CREATE DATABASE IF NOT EXISTS `base` DEFAULT CHARACTER SET `latin1` DEFAULT COLLATE `latin1_general_ci` --------------   -------------- DROP TABLE IF EXISTS `nombre` --------------   -------------- CREATE TABLE `nombre` ( `id` smallint unsigned NOT NULL primary key, `mess` varchar(25) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED --------------   -------------- insert into `nombre` (`id`,`mess`) values (7, 'sept'), (2, 'deux'), (10, 'dix'), (4, 'quatre'), (1, 'un'), (8, 'huit'), (6, 'six'), (3, 'trois'), (5, 'cinq'), (9, 'neuf') --------------   -------------- select * from `nombre` --------------   +----+--------+ | id | mess | +----+--------+ | 1 | un | | 2 | deux | | 3 | trois | | 4 | quatre | | 5 | cinq | | 6 | six | | 7 | sept | | 8 | huit | | 9 | neuf | | 10 | dix | +----+--------+ -------------- DROP TABLE IF EXISTS `test` --------------   -------------- CREATE TABLE `test` ( `clef` integer unsigned NOT NULL auto_increment primary key, `val` smallint unsigned NOT NULL, CONSTRAINT `FK_01` FOREIGN KEY (`val`) REFERENCES `nombre` (`id`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED --------------   -------------- insert into `test` (`val`) values (7),(5),(6),(4),(1),(10),(8),(3),(2),(9) --------------   -------------- select t2.id, t2.mess, t1.clef, t1.val from `test` as t1 inner join `nombre` as t2 on t2.id = t1.val order by t2.id --------------   +----+--------+------+-----+ | id | mess | clef | val | +----+--------+------+-----+ | 1 | un | 5 | 1 | | 2 | deux | 9 | 2 | | 3 | trois | 8 | 3 | | 4 | quatre | 4 | 4 | | 5 | cinq | 2 | 5 | | 6 | six | 3 | 6 | | 7 | sept | 1 | 7 | | 8 | huit | 7 | 8 | | 9 | neuf | 10 | 9 | | 10 | dix | 6 | 10 | +----+--------+------+-----+ -------------- COMMIT --------------   Appuyez sur une touche pour continuer...

---

J'espère que cela va répondre à votre attente.

@+

Citation:

---

Envoyé par Artemus24

Traduction : il veut un ordre apparent et non un ordre de stockage des lignes dans la table.

---

Un grand merci à tous...
Non, Artemus, avec ORDER BY, mes lignes sont bien classées selon mes index (et ça, au moins, je sais faire !), ou alors je n'ai pas compris votre message, ce qui est parfaitement possible...
Ce que je souhaitais, c'est un classement automatique (ou automatisé) de mes COLONNES de façon à ce que le SELECT me retourne les habilitations classées par ordre numérique d'opération (ceci afin de les afficher dans l'ordre et par famille sur le masque de saisie) puisque je ne sélectionne qu'un seul utilisateur à la fois, mais en affichant l'ensemble des habilitations possibles (cases à cocher).
Visiblement, la seule solution est "ALTER TABLE... AFTER".
A moi, donc de gérer l'endroit de l'insertion car j'ai téléchargé le document conseillé par Paraffine et c'est bien clair...
Je vais creuser...
En effet, l'application que je développe est appelée à couvrir un périmètre de plus en plus étendu. Actuellement, je ne gère que les adhérents et la comptabilité mais, ensuite, il y aura la gestion du journal (facturation / règlement à l'éditeur, gestion du routage...) puis celle des AG régionales, etc. ! (je n'ai rejoint l'équipe que depuis peu et, donc je débute l'application dont certaines fonctions lui sont, déjà nécessaires, d'où le fait des ajouts a posteriori.)
Bien sûr, je peux insérer mes colonnes manuellement au fur et à mesure de mon développement mais, si "moi" je sais faire, il est quasi certain qu'aujourd'hui, je suis le seul :( et je ne veux pas qu'en cas de pépin, l'asso dépende de moi d'où le fait que je voudrais que tout ça se fasse depuis un masque de saisie permettant à de purs utilisateurs (certains ont plus de 80 ans...) de n'avoir que ces masques à saisir...
... A moins qu'un nouvel adhérent, compétent et issu de nos services informatiques rejoigne notre amicale (et mette mon truc à la poubelle pour le réécrire avec méthode :D !)

Citation:

---

Envoyé par novembrezoulou

je pensais qu'il existait un moyen de reclasser les champs avec celui ajouté (en fin de table) sans me préoccuper de l'endroit d'insertion une fois cette insertion réalisée.

---

En fait je pense que phpMyAdmin, quand il vous permet de reclasser les colonnes par ordre "alphabétique", fait un traitement et non un simple ordre SQL; lecture des colonnes dans le catalogue de la base, tri, et ré-ordonnancement grâce à un "ALTER TABLE" qui doit ressembler à (je suppose que la clé reste en premier, quand même ?):

Code:

---

1 2 3 4

ALTER TABLE `habilitationsmembres` MODIFY COLUMN `1.02` TINYINT(1) AFTER `1.01`, MODIFY COLUMN `1.03` TINYINT(1) AFTER `1.02`, MODIFY COLUMN `1.04` TINYINT(1) AFTER `1.03`, ...

---

Quand vous vous sentirez prêt pour vous lancer dans les jointures et la modélisation, faites-nous signe (c'est quand même un peu dommage de faire des développements sur un modèle peu, heu, orthodoxe, comme Tatayo l'a subodoré...)

Une modélisation plus "autorisée" consiste à recenser les utilisateurs dans une table "membres" avec l'identifiant (la clé) aminum.
Après, une table de "relation" fait le rapprochement entre les utilisateurs et les opérations par exemple habilitationmembre - nouvelle mouture - avec : aminum, codeopenum, autorise (O/N), date de début et de fin - par exemple (cela dit, la gestion des dates, c'est bien, mais cela complique les requêtes). Si on veut gérer les habilitations explicitement pour chaque membre, le nombre de lignes de cette table vaudra (nombre de membres) * (nombre d'opérations) (sauf membres et opérations inactifs)

Ensuite pour savoir si une personne (un membre actif) est autorisée sur une opération donnée on fait :

Code:

---

1 2 3 4

SELECT habilitationmembre.autorise FROM habilitationmembre WHERE aminum = valeur_aminum AND habilitationmembre.codeopenum= valeur_code_operation

---

(sans gestion des dates ici)

Pour récupérer l'ensemble des opérations autorisées d'un coup, par contre, il faut faire une boucle dans le programme pour lire les enregistrements successifs (triés par codeopenum).

En tout cas, bonne continuation et bonne année !

Citation:

---

En fait je pense que phpMyAdmin, quand il vous permet de reclasser les colonnes par ordre "alphabétique", fait un traitement et non un simple ordre SQL; lecture des colonnes dans le catalogue de la base, tri, et ré-ordonnancement grâce à un "ALTER TABLE" qui doit ressembler à (je suppose que la clé reste en premier, quand même ?):

---

Non... C'est moi qui ai mal vu et ce sont bien les lignes qui ont été classées et non les colonnes...
J'ai regardé les jointures il y a quelques temps et fait quelques exercices mais mon projet est très simple et, c'est vrai, je fais en deux requêtes ce que je pourrais faire en une seule... peut mieux faire auraient dit mes profs...

Je vais commencer par mieux maîtriser les bases avant de me lancer... mais je vais m'y coller !
Ça fait travailler la tête et, en retraite, ce n'est pas neutre car il faut continuer à solliciter le cerveau :D

Je vais passer le post en résolu
Merci à tous et belle année, espérons plus sereine que celle que nous venons de quitter

Salut à tous.

@ NovembreZoulou : après relecture des messages, j'avoue ne plus très bien comprendre ce que vous cherchez à faire.

Je vois trois idée différentes qui se dégage de ce sujet :

1) j'ai cru comprendre que vous désirez trier les lignes qui ont été stockées dans votre table.
Cela ne sert à rien, sauf pour des raisons de performances dans une requête qui est trop longue à s'exécuter.
C'est ce que propose Tatyo avec la commande : "alter table ma_table order by col1, col2".
Franchement cela n'as aucune raison d'être dans une application qui a été bien modélisée.

2) j'ai compris que vous ne saviez pas ordonner les lignes à l'affichage.
C'est ce que j'ai nommé l'ordre apparent des lignes.
J'ai indiqué par différents exemples, les résultats que l'oin peut obtenir sur l'ordre apparent à l'affichage.
La solution que je vous ai proposé concerne une jointure avec un "order by".
Mais je crois comprendre que ce n'est pas ce que vous cherchez à faire.

3) l'idée de paraffine #7 semble vous convenir, car vous désirez trier les noms des colonnes de votre table.
Si pour une raison quelconque vous avez besoin d'ajouter de nouvelles colonnes dans votre table, c'est que vous avez un problème de modélisation.
Une table ne doit pas stocker un tableau de données, comme on le ferait sous Excel.
Vous ne respectez pas les formes normales puisque une colonne de votre table peut dépendre d'une autre colonne qui n'est pas la clef.
Comme vous avez un problème de modélisation, l'astuce d paraffine n vous sert à rien.

Citation:

---

Envoyé par NovembreZoulou

En fait, je n'ai pas de "modélisation" car... je ne sais pas en faire !

---

C'est par la modélisation que l'on commence la conception d'un base de données.

Citation:

---

Envoyé par NovembreZoulou

mon truc a le mérite de fonctionner et de suffire à mes utilisateurs

---

Je comprends surtout que vous avez créé une usine à gaz !

Citation:

---

Envoyé par NovembreZoulou

Non, Artemus, avec ORDER BY, mes lignes sont bien classées selon mes index (et ça, au moins, je sais faire !), ou alors je n'ai pas compris votre message, ce qui est parfaitement possible...

---

Je ne suis pas le seul à ne pas comprendre votre besoin, sauf paraffine.
Mais sur ce point, j ne lui donne pas raison.

Citation:

---

Envoyé par NovembreZoulou

Ce que je souhaitais, c'est un classement automatique (ou automatisé) de mes COLONNES

---

Là aussi, je ne comprends pas le besoin.

Si vous avez besoin que la colonne "col2" soit avant la colonne "col1" dans un select, il suffit d'écrire :

Code:

---

select col2, col1 from ma_table

---

Et peu importe où se trouve les colonnes "col1" et col2" dans la table.

Pour résumer mon sentiment :
--> vous ne savez pas vous exprimez correctement sur la nature de votre problème.
--> vous avez un sérieux problème de modélisation.
--> vous ne devez pas travailler au fil de l'eau mais définir une fois pour toute vos besoins.
--> une base de données relationnelle n'est pas un tableur. Vous devez respecter les formes normales.
--> l'ordre de stockages des lignes, ou l'ordre des noms des colonnes dans une table, n'ont aucune importance.
--> C'est au langage de programmation (comme php) de faire la présentation de vos données et non à une quelconque requête. C'est fréquemment une erreur de débutant de croire cela.

P.S.: changer le titre de votre sujet. Mettez quelque chose comme "comment positionner un nom de colonne dans ma table".

@+

Re bonjour,
Je ne pensais pas revenir sur le sujet...

Comme je l'ai largement dit, mon niveau est celui d'un "microteur" moyen qui essaye d'avancer et j'ai bien dit, aussi, que je ne savais pas modéliser une base (et donc que ce problème est réel)...
La raison en est très simple : les divers tutos PHP que j'ai consulté m'indiquent comment insérer, supprimer, modifier des données dans une base mais aucun ne parle de cette modélisation (ce n'est, je l'accorde, pas leur but).
Une recherche sur le moteur de "developpez" m'envoie sur des questions posées par les membres mais pas vers des tutos traitant du sujet (ou j'ai mal rédigé ma demande...).

Je veux bien repousser mon "seuil de Peter's" en informatique... et je suis preneur de tout tutoriel m'expliquant ce qu'est une modélisation car, même si j'imagine que c’est la description de la base, je ne peux deviner précisément ce dont il s'agit.
Je vois que beaucoup, ici, prennent du temps pour expliquer aux "bleus" (j'ai fait mon armée en... 1968 !) et je reste toujours preneur d'informations. Ne pas penser, donc, que je néglige des conseils mais, concernant cette "modélisation" il faudrait déjà que je sache ce qui se cache précisément derrière ce terme pour juger de la qualité ou non de la mienne, je jour où j'en aurai fait une... Mais je suis tout à fait conscient qu'avec une telle organisation, les choses iraient mieux !.

J'ai remplacé un informaticien de métier (bénévole) qui a mis en place des outils "Excel" ultra sophistiqués mais... écrits en VB, langage que je ne maîtrise pas du tout et le simple fait d'avoir à modifier le tableau comptable de 2019 en2020 m'a été quasi impossible car l'outil est bourré de contrôles de saisie évitant, par exemple, des dates hors exercice comptable. Ajoutez que certains utilisateurs les lisaient avec open office ou libre office et vous aurez deviné la tête des retours... En plus, la consolidation des +-50 antennes de l'asso se faisait par des "copier / coller" sur un récap...
Dans l’urgence, je suis donc passé à ce que connais (même mal...) car, en fin d'année, il faudra bien clore l'exercice comptable (les écritures sont, ensuite reprises (regroupées !) par le trésorier qui les saisit manuellement dans le logiciel commercial spécifique "EBP").

Donc... rien ne m'empêche de revoir mon "machin" une fois l'exercice comptable clos puisque j'aurai tout mon temps. Dans l'immédiat, je gère les écritures, les regroupe et donne au trésorier des infos suffisantes pour lui. Le vrai problème (pour autant que c'en soit un) c'est que ca a donné des appétits à d'autres compartiments de l'asso qui voudraient, eux aussi, un outil... Mais là, si je dispose d'un bon tuto, je pourrai pratiquer avec davantage de méthode...

... j'aurai encore besoin de vos tuyaux :D

Salut NovembreZoulou.

Votre pseudo m'intrigue. Auriez-vous été radio amateur ?

Vous êtes de bonne volonté, enfin je le comprends ainsi, mais modéliser une base de données qui ne l'a jamais été, revient à tout réécrire.
C'est un travail d'une ampleur qui va demander beaucoup de temps, et de connaissance que vous n'avez pas pour l'instant.
Vous retrouverez certe, une base de données conforme aux normes, sans problème de modélisation, ni de performance.
Mais au final, fonctionnellement, rien n'aura changé.
Merci pour vos explications, mais votre machin devra être maintenu, malgré les erreurs de conceptions.

Citation:

---

Envoyé par NovembreZoulou

... j'aurai encore besoin de vos tuyaux

---

Désolé nous ne faisons pas de plomberie, ni d'usine à gaz.
Nous essayons de résoudre les problèmes et à l'occasion, d'inculquer les bonnes pratiques.

Si vous avez des questions, n'hésitez pas, nous sommes là pour ça.
Mais prenez l'habitude de donner le descriptif de vos tables, d'un jeu d'essai, d'explication claire sur votre problématique et de la solution attendue.

@+

remettez votre ouvrage, polissez le, sans cesse, et le repolissez...
Je remettrai certainement tout à plat lorsque l'urgence sera passée...
Pour le pseudo...
Oui, j'ai fait de la radio, mais c'était à bord d'un objet volant identifié !
Les lettres "NZ" sont les dernière de l'immatriculation de l'avion école que j'ai tant fait souffrir lors de mes atterrissages ratés... :(
Je lui devais bien ça !
J'ai la qualif "B", donc avions à train rentrant et à hélice à pas variable... mais c'est du hors sujet sur ce forum !
(pour la suite, sur ce sujet... on peut faire en MP)

Bonne année à tous, et en particulier à vous, courageux NZ !  


Je découvre tardivement la discussion que vous avez ouverte (et marquée résolue), mais elle est dans un forum que je ne fréquente qu’occasionnellement.

Pour repartir du bon pied, concernant l’apprentissage de la modélisation des bases de données, je vous engage à lire les bons auteurs. Il existe fondamentalement l’ouvrage remarquable de D. Nanci (RIP) et B. Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), c’est l’ouvrage de référence. Le chapitre à étudier est le chapitre 7 (« Modélisation conceptuelle des données »).
Il vous faut aussi un bon outil pour construire votre MCD (modèle conceptuel des données), et là, sans hésiter une seconde, c’est Looping qu’il faut utiliser, gracieusement proposé par le très sympathique et désintéressé professeur Patrick Bergougnoux (grand merci Paprick !)

A noter en passant que Looping se charge de générer le code SQL de création des tables.

N'hésitez pas à acquérir l’ouvrage proposé par Patrick, « Modélisation conceptuelle des données », il est plein d’exemples fort utiles. Le coût en est modeste et les bénéfices reversés à Action contre la faim.

Concernant votre problème initial : ordre des lignes dans une table, ne soyez pas étonné que cet ordre ne concerne en rien les lignes, en effet une table (dotée d’une clé) est un ensemble, et la théorie des ensembles nous rappelle que les éléments d’un ensemble ne sont en aucune façon sujets à être ordonnés. A l’opposé, les enregistrements d’un fichier peuvent être ordonnés, mais on tombe là dans la programmation que je pratiquais au milieu des années soixante, et depuis on a eu toute latitude pour évoluer (à ce sujet, je fais référence à l’article fondateur de E.F. Codd, A Relational Model of Data for Large Shared Data Banks, paru en 1970)...

Les principaux forums traitant de la modélisation des données :

Schéma

Merise

Et bien entendu le récent Looping

Sans oublier le forum dédié à l’excellent PowerAMC, AGL coûtant hélas ! la feau des pesses...

NZ, n'hésitez pas à poster dans le forum Looping, vous y trouverez toute l'aide nécessaire, de la part de concepteurs compétents et bénévoles !

@ fsmrel
Hasard des évènements...
Je viens de télécharger votre tuto sur mysql workbench... (http://fsmrel.developpez.com/basesre...les/workbench/) et je me dis qu'il me manque toutes les bases pour faire quelque chose de propre...
On ne s'improvise pas développeur (ou toute autre spécialité)...
Je vais retrouver (je l'espère) de la disponibilité vers mi février, après les opérations de fin d'exercice 2020.
J'essayerai de m'y coller, simplement pour... l'avoir fait car en m'y attaquant maintenant, il est évident que je ne serai jamais un pro de la chose...
Les défis, ça pimente la vie et ça fait travailler le cerveau.
Je regarderai l'outil que vous proposez mais, déjà, je vois qu'il me faudra tout remettre à plat.
Donc, c'est comme en aviation, je vais commencer par les tours de piste accompagné (de tutoriels) avant de faire un vol solo... Le lâcher viendra plus tard (il ne faut quand-même que je traîne trop... je suis né en 1948 !)
Encore merci de l'intérêt que tous, vous avez porté à mon interrogation... dont j'ignorais où elle me conduirait !

Citation:

---

Envoyé par novembrezoulou

...
Donc, c'est comme en aviation, je vais commencer par les tours de piste accompagné (de tutoriels) avant de faire un vol solo... Le lâcher viendra plus tard

---

C'est la bonne méthode et on est là pour vous aider !

Citation:

---

(il ne faut quand-même que je traîne trop... je suis né en 1948 !)

---

Tant que le cerveau ne part pas en sauce blanche !!!!

A +

Il n'est jamais trop tard pour apprendre, même à 72 ans !

Je suis évidemment d'accord avec les conseils donnés par mes prédécesseurs et vous invite, comme fsmrel (qui est un peu plus vieux que vous et au cerveau toujours alerte), à rejoindre le forum Schéma pour discuter de la conception de votre base de données.
Mais avant de vous lancer dans la réalisation d'un Modèle Conceptuel de Données (MCD), je vous recommande d'écrire vos règles de gestion des données. Pour ça aussi, nous pouvons vous aider dans le forum Schéma.

Le retour éventuel vers le forum MySQL se fera après la conception et l'implémentation de votre base de données qui pourra alors, comme vous le souhaitez, être manipulée via une interface par des non-informaticiens.

Je vous mets l'eau à la bouche : l'ajout d'une opération accessible aux utilisateurs reviendra à insérer non pas une colonne mais une ligne dans une table. Pour la gestion des droits sur cette nouvelle opération, il faudra ajouter davantage de lignes mais ce ne sera pas non plus très compliqué.

Bon courage ! Vous vous apprêtez à aborder un domaine passionnant et qui fera effectivement pas mal travailler votre cerveau.