Discussion :

[MarcBl]

Bonjour,
C'est mon premier post dans ce forum. Je programme un petit site juste pour un besoin personnel. Il s'agit d'une gestion de base de données avec mes biens acquis et ceux que je désire visible depuis Internet afin d'éviter les doubles achats.
Voilà, j'ai un petit problème en SQL (enfin je pense) : j'ai une table dans ma base de données qui contient plusieurs champs dont le champ "IDSouhaits" qui est un Index qui (dans PHPMyAdmin) choisi le premier nombre de libre et l'assigne à la nouvelle fiche.
Bêtement, j'ai pensé que la requête ci-dessous ferait la même chose mais n'en est rien. Y' a t'il un moyen d'y parvenir, ou dois-je m'en remettre à la fonction SQL COUNT ?

Code :

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

INSERT INTO `Souhaits` (`IDSouhaits`, `TitreMedia`, `InfoComplementaires`, `TypeMedia`, `VendeursTrouves`, `PrixOfficiel`, `AchatEnCours`, `AchatUrgent`, `ASupprimer`) VALUES ('', 'Test bidonné', '', 'JV', 'AUCUN', '0', '0', '0', '0')

J'ai testé la création d'une nouvelle fiche dans ma table avec PHPMyAdmin, mais la requête SQL affichée est la même.

[al1_24]

le champ "IDSouhaits" (...) est un Index qui (dans PHPMyAdmin) choisit le premier nombre de libre et l'assigne à la nouvelle fiche.

Tu parles d'un identifiant auto-incrémenté ?

Le plus simple est de ne pas lui attribuer de valeur à l'insertion de la ligne :

Code :

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

1
2
3
4
INSERT INTO `Souhaits` 
    (`TitreMedia`, `InfoComplementaires`, `TypeMedia`, `VendeursTrouves`, `PrixOfficiel`, `AchatEnCours`, `AchatUrgent`, `ASupprimer`)
VALUES
    ('Test bidonné', '', 'JV', 'AUCUN', '0', '0', '0', '0')

Par ailleurs, il est toujours préférable de respecter le type des colonnes lors des insertions et mises à jour. Si les colonnes `PrixOfficiel`, `AchatEnCours`, `AchatUrgent` et `ASupprimer` sont de type numérique, c'est la valeur 0 qu'il faut leur affecter et non la chaîne '0'.

[MarcBl]

Par ailleurs, il est toujours préférable de respecter le type des colonnes lors des insertions et mises à jour. Si les colonnes `PrixOfficiel`, `AchatEnCours`, `AchatUrgent` et `ASupprimer` sont de type numérique, c'est la valeur 0 qu'il faut leur affecter et non la chaîne '0'.

Sinon :
Merci, je viens de résoudre ce petit problème.

Tu parles d'un identifiant auto-incrémenté ?

Le plus simple est de ne pas lui attribuer de valeur à l'insertion de la ligne :

Code :

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

1
2
3
4
INSERT INTO `Souhaits` 
    (`TitreMedia`, `InfoComplementaires`, `TypeMedia`, `VendeursTrouves`, `PrixOfficiel`, `AchatEnCours`, `AchatUrgent`, `ASupprimer`)
VALUES
    ('Test bidonné', '', 'JV', 'AUCUN', '0', '0', '0', '0')

C'est bien un auto-incrémenté, je n'avait plus le terme en tête. J'ai déjà essayé sans le champ IDSouhaits, mais la requête envoie une erreur : le champ IDSouhaits est manquant.

[escartefigue]

bonjour,

Pouvez-vous communiquer le script DDL de création de la table (ordre complet CREATE TABLE)

[MarcBl]

bonjour,

Pouvez-vous communiquer le script DDL de création de la table (ordre complet CREATE TABLE)

Qu'est-ce qu'un script DDL ? Si c'est le script de création de la table, alors la voici ci-dessous, sinon je vous prie de m'aider à vous aider pour... m'aider.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE `Souhaits` (
  `IDSouhaits` varchar(20) NOT NULL,
  `TitreMedia` text NOT NULL,
  `TypeMedia` varchar(20) DEFAULT NULL,
  `InfoComplementaires` text,
  `VendeursTrouves` text,
  `PrixOfficiel` int(11) NOT NULL DEFAULT '0',
  `AchatEnCours` int(11) NOT NULL DEFAULT '0',
  `AchatUrgent` int(11) NOT NULL DEFAULT '0',
  `ASupprimer` int(11) NOT NULL DEFAULT '0'
) ENGINE=InnoDB;

[escartefigue]

C'est bien ça le DDL (Data Definition Language) : c'est à dire la partie du langage SQL qui permet de créer (CREATE), modifier (ALTER) ou supprimer (DROP) des objets de la base de données.
On voit dans ce script que la colonne IDSouhaits n'est absolument pas un identifiant attribué par le SGBD, c'est à dire un identifiant auto-incrémenté pour MySQL, mais un varchar sans valeur par défaut. De ce fait, c'est non seulement un très mauvais type de données pour une clef primaire (encombrant, sensible à la collation, sensible aux changements de longeur en cas de mise à jour de la valeur, et le plus souvent d'un contenu signifiant donc instable), mais aussi une colonne dont la valeur doit obligatoirement être fournie lors de l'insert puisqu'aucune valeur par défaut n'est donnée.

Remplacez ce type varchar par un type integer avec la propriété auto_increment et le problème sera résolu

EDIT et j'oubliais l'essentiel : il faut ajouter la contrainte Primary Key sur la colonne IDSouhaits

Egalement, tant qu'à faire, renommez la table "Souhaits" en "Souhait" et la colonne "IDSouhaits" en "IDSouhait"
Pour la table : c'est une évidence que toute table peut contenir plusieurs occurrences, le "s" n'est donc pas requis, de plus, le nom de la table vient de "l'individu" au stade conceptuel, matérialisé par le type d'entité. D'où le singulier.
Pour la colonne : là c'est encore pire, par définition, un identifiant sert à reconnaitre une et une seule ligne dans la table, le "s" est donc interdit !

[SQLpro]

Autre petite chose en matière de terminologie...

Le mot "champ", n'existe pas dans le vocabulaire consacré aux bases de données. Un champ est une zone : champ de patates pour le paysan, champ opératoire pour le chirurgien, champ de saisie dans un formulaire....
Or un SGBDR n'a pas de formulaire.... Mais des tables avec des lignes et des colonnes...
A lire : https://sqlpro.developpez.com/cours/sqlaz/erreurs/#L2

A +

[MarcBl]

Primo, merci SQLPro je vais lire ça le plus vite possible

Edit : PHPMyAdmin fait l'erreur du mot champs dans sa traduction française...

C'est bien ça le DDL (Data Definition Language) : c'est à dire la partie du langage SQL qui permet de créer (CREATE), modifier (ALTER) ou supprimer (DROP) des objets de la base de données.
On voit dans ce script que la colonne IDSouhaits n'est absolument pas un identifiant attribué par le SGBD, c'est à dire un identifiant auto-incrémenté pour MySQL, mais un varchar sans valeur par défaut. De ce fait, c'est non seulement un très mauvais type de données pour une clef primaire (encombrant, sensible à la collation, sensible aux changements de longeur en cas de mise à jour de la valeur, et le plus souvent d'un contenu signifiant donc instable), mais aussi une colonne dont la valeur doit obligatoirement être fournie lors de l'insert puisqu'aucune valeur par défaut n'est donnée.

Remplacez ce type varchar par un type integer avec la propriété auto_increment et le problème sera résolu

EDIT et j'oubliais l'essentiel : il faut ajouter la contrainte Primary Key sur la colonne IDSouhaits

Egalement, tant qu'à faire, renommez la table "Souhaits" en "Souhait" et la colonne "IDSouhaits" en "IDSouhait"
Pour la table : c'est une évidence que toute table peut contenir plusieurs occurrences, le "s" n'est donc pas requis, de plus, le nom de la table vient de "l'individu" au stade conceptuel, matérialisé par le type d'entité. D'où le singulier.
Pour la colonne : là c'est encore pire, par définition, un identifiant sert à reconnaitre une et une seule ligne dans la table, le "s" est donc interdit !

Dans le même fichier SQL qui créée mes tables, il y avait ça aussi, bien après :

Code :

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

1
2
ALTER TABLE `Souhaits`
  ADD UNIQUE KEY `Index_Souhait` (`IDSouhaits`);

Mais il n'y avait rien sur l'auto-incrémentation. Il semble que je l'avais oublié lors de la première création de mes tables.
Autant pour moi. Et désolé de vous avoir dérangé pour rien.

Edit :

[SQLpro]

Primo, merci SQLPro je vais lire ça le plus vite possible

Edit : PHPMyAdmin fait l'erreur du mot champs dans sa traduction française...

Normal il s'agit d'un logiciel non professionnel et cette erreur de traduction est courante hélas....

A +

[escartefigue]

Dans le même fichier SQL qui créée mes tables, il y avait ça aussi, bien après :

Code :

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

1
2
ALTER TABLE `Souhaits`
  ADD UNIQUE KEY `Index_Souhait` (`IDSouhaits`);

Oui, mais une contrainte UNIQUE ne suffit pas, il manque la contrainte PRIMARY KEY !
les différences sont énormes :

• d'une part une colonne UNIQUE peut tout à fait être NULLABLE, contrairement à une PK qui est obligatoirement NOT NULL ;
• d'autre part la PK sert à vérifier l'intégrité des données grâces aux contraintes REFERENCE, et ça c'est fondamental !

Et comme dit plus haut, un type varchar est ce qu'on peut faire de pire pour une PK, à remplacer par un type INTEGER avec la propriété AUTO_INCREMENT.

Attention aussi au typage des autres colonnes, le type TEXT, non normatif, est le plus souvent aussi symptomatique d'une erreur de modélisation, et un prix en integer ne convient que si aucune décimale n'est requise.

[SQLpro]

...
d'autre part la PK sert à vérifier l'intégrité des données grâces aux contraintes REFERENCE, et ça c'est fondamental !
...

Tu oublies juste qu'une contrainte UNIQUE peut aussi servir de référence d'intégrité à une clé étrangère.... Chose que je montre toujours dans mes cours.....

Petite demo...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
CREATE TABLE T_PATIENT_PAT
(PAT_ID           INT IDENTITY PRIMARY KEY,
 PAT_NUMSECU      CHAR(13) NULL UNIQUE,
 PAT_NOM          VARCHAR(32) NOT NULL);
 
CREATE TABLE T_ORDONANCE_ODC
(ODC_ID           INT IDENTITY PRIMARY KEY,
 PAT_ID           INT NOT NULL FOREIGN KEY REFERENCES T_PATIENT_PAT (PAT_ID),
 ODC_DATETIME     DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP);
 
CREATE TABLE T_REMBOURSEMENT_CMU_RBC
(RBC_ID           INT IDENTITY PRIMARY KEY,
 PAT_NUMSECU      CHAR(13) NOT NULL FOREIGN KEY REFERENCES T_PATIENT_PAT (PAT_NUMSECU),
 RBC_MONTANT      NUMERIC(16,2) NOT NULL);

A +

[escartefigue]

Je n'oublie rien, mais ces contraintes sont facultatives alors que les contraintes reference vis à vis des PK sont déployées automatiquement, sous réserve qu'on utilise un logiciel de modélisation, ce que je recommande très fortement, ça évite de nombreuses erreurs bien trop fréquentes.
En général, les contraintes liées à des colonnes ou groupes de colonnes unique non PK sont implémentées pour les CIF (inclusion, exclusion, partitionnement...)

[MarcBl]

Alors pour être franc, je n'ai rien appris du SQL à ma grande honte. Tout mon savoir est, pour le moment, appris en copiant-collant les requêtes SQL affichées par PHPMyAdmin. Mais, promis, dès que j'aurais fini la V1 de mon site, je m'y met sérieusement, tout comme pour le PHP 8. Vous voyez, il me reste encore beaucoup de chemin à parcourir, et donc beaucoup de bonheur aussi.

[escartefigue]

Le problème de PHPMyAdmin est qu'il ne propose pas de modélisation conceptuelle, on modélise directement les tables, c'est la raison pour laquelle les modèles de données MySQL sont trop souvent très mal faits

[MarcBl]

Le problème de PHPMyAdmin est qu'il ne propose pas de modélisation conceptuelle, on modélise directement les tables, c'est la raison pour laquelle les modèles de données MySQL sont trop souvent très mal faits

Je veux bien le croire, mais pour faire un petit site rapidement sans vraiment rien connaitre en SQL, c'est pratique. Mais une fois, ma V1 faite, j'ai encore plusieurs facteurs à améliorer : passer à PHP 8, apprendre la structure et l'utilisation de SQL (MySQL pour être précis)… J'en salive d'avance.