Discussion :

[cseb73]

Bonjour à tous,

les nouvelles sous-categories que je crée ne sont pas pris en compte par mes autres tables,

je m'explique, j 'ai une table article ,categorie et sous categorie.

la table article n'enregistre plus les sous categories qui viennent d'etre crée.

je lance la modification dans PhpMyadmin ,

il lance l'update et ecrit meme la requete apres resultat!!!


Mais en verifiant la sous categorie de l'article elle revient sur le dernier numero de la sscategorie crée reconnu et non la derniere sscategorie crée et selectionné.


A priori cela est arrivé apres avoir modifié le nom d'une souscategorie et apres en avoir crée une nouvelle.

je ne sais pas si je suis claire, mais j'ai besoin d'un coup de main,

si ca parle à quelqu'un merci d'avance!

[guigouz]

Pourrais-tu nous donner la structure de tes tables ?
Est-ce que tu utilises innoDB ou MyISAM ?

Je dois avouer également que je n'ai pas entièrement compris ce que tu voulais mais ça sera plus clair avec les réponses aux questions ci-dessus.

Bonsoir bonsoir

[Alain Defrance]

Bonjour,

Je dois avouer également que je n'ai pas entièrement compris ce que tu voulais

+1

Pourrait-tu nous monter des exemples, et le script de création de ta base afin qu'on puisse t'aider.

Bonne journée.

[cseb73]

Merci pour vos reponses,

j'utilise MyISAM et en fait ca tourne depuis un moment sans probleme et la, mis à part se probleme de

nouvelle sous categorie tous fonctionne tres bien!

En gros
voici la structure

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
 
--
-- Structure de la table `categorie`
--
 
CREATE TABLE IF NOT EXISTS `categorie` (
  `id_categorie` tinyint(4) NOT NULL auto_increment,
  `logo_categ` varchar(30) default NULL,
  `nom_categorie` varchar(50)  NOT NULL default '',
  `intro_categorie` text ,
  PRIMARY KEY  (`id_categorie`)
)
 
 
--
-- Structure de la table `sscategorie`
--
 
CREATE TABLE IF NOT EXISTS `sscategorie` (
  `id_sscategorie` varchar(5)  NOT NULL default '',
  `nom_sscategorie` varchar(25) NOT NULL default '',
  `categorie_id` tinyint(4) NOT NULL default '0',
  UNIQUE KEY `id_sscategorie` (`id_sscategorie`)
) 
 
 
 
 
--
-- Structure de la table `articles`
--
 
CREATE TABLE IF NOT EXISTS `articles` (
  `reference` varchar(10) NOT NULL default '',
 
  `nom_article` varchar(50) NOT NULL default '',
 
  `prix_article` decimal(5,2) NOT NULL default '0.00',
 
  `definition_article` text  NOT NULL,
 
  `photo_article` varchar(50)  NOT NULL default '',
 
  `sscategorie_id` tinyint(5) NOT NULL default '0',
 
  PRIMARY KEY  (`reference`)
)

pour exemple la derniere sscategorie reconnu est la 127 ,malgré la 128 et 129 existante depuis.
sur article je prend la reference (exemple 12363) et modife son sscategorie_id 31 en 128.

et tous ca dans mysql directement!!!

il indique bien l'action sql ,

mais en revenant sur la reference il a repris la sscategorie 127

mais si je la met en une sscategorie inferieur a 127 il l'a garde!

[Alain Defrance]

Pourrait-on voir la requête qui ne marche pas concernant la modification ?

[cseb73]

je fais la requête manuellement dans phpmyadmin via la table article ,
et modifie la reference 1515

cela donne ca en sql affiché !

Code :

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

1
2
3
 
UPDATE `bddname`.`articles` SET `sscategorie_id` = '128' 
WHERE `articles`.`reference` = '1515' LIMIT 1 ;

j'ai utilisé les outils de l'interface (repair , analyse ,mis à part le fluch qui ne m'est pas autorisé) mais sans grande conviction à la vu des resultats (néants).

j'ai aussi enlever les index des trois tables ainsi que les clés primaire et les ai remis!
mais toujours pareil!!!

[Alain Defrance]

Outre le problème technique que tu rencontre, je ne parviens pas a cerner ton problème, ni ce que tu cherche a faire.
Tu souhaite réattribuer une clé déja utilisé ?
Ou alors tu cherche a combler les trous d'identifications ?

Si c'est le cas c'est très vivement déconseillé : en cas d'archivage par exemple, tu va te retrouver avec un conflit au niveau de l'identification.

Ensuite il généralement conseillé d'identifier ses tuples avec des entiers, et non des chaines de caractère car ces identifications permettent l'utilisation de séquence par exemple

Dans tous les cas, il est absolument a éviter de changer l'identifiant tout au long de la durée de vie d'un objet.

[cseb73]

je cherche tous simplement à créer une nouvelle sscategorie

et quel reste dans article quand je lui attribue cette nouvelle sscategorie

sinon je ne peux plus créer d'article dans une nouvelle sous categorie!

supprimer la table sscategorie et la remettre serai utile ?.

[Alain Defrance]

Salut,

Premièrement ta structure est source d'ennui et je pense gagnerais a être modifié.

1/ Aucun contrainte d'intégrité n'est définit, cela peut entrainer plusieurs problèmes (lenteur car pas d'index, intégrité non respecté etc ...)

2/ NULL est un marqueur signalant l'absence de valeur, aussi lorsque l'on met '' comme valeur on donne bien une valeur "vide", mais en ancun cas on spécifie l'absence de valeur.
Ceci peut être gênant, nottament au niveau des fonction d'agrégations qui prennent un compte ce marqueur NULL.
Il n'est donc pas judicieux de mettre un champ a NOT NULL puis un default à ''. Dans ce cas rien ne nous empechent de laisser le champ NULLABLE (c'est fait pour ça). cf

3/ On a pour convention de ne pas nommer les entité au pluriels, et surtout pas d'en mettre certaines au singulier et d'autres au pluriels.

Je propose quelque chose comme ceci :

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
 
--
-- Structure de la table `categorie`
--
 
CREATE TABLE IF NOT EXISTS `categorie` (
  `id_categorie` tinyint(4) NOT NULL AUTO_INCREMENT,
  `logo_categ` varchar(30) NULL,
  `nom_categorie` varchar(50)  NOT NULL ,
  `intro_categorie` text NULL,
  CONSTRAINT PK_CATEGORIE PRIMARY KEY  (`id_categorie`)
) ENGINE = innodb;
 
 
--
-- Structure de la table `sscategorie`
--
 
CREATE TABLE IF NOT EXISTS `sscategorie` (
  `id_sscategorie` tinyint(5) NOT NULL AUTO_INCREMENT,
  `nom_sscategorie` varchar(25) NOT NULL,
  `categorie_id` tinyint(4) NOT NULL,
  CONSTRAINT PK_SSCATEGORIE PRIMARY KEY(id_sscategorie),
  CONSTRAINT FK_SSCATEGORIE_CATEGORIE FOREIGN KEY (categorie_id) REFERENCES categorie(id_categorie)
) ENGINE = innodb;
 
 
 
--
-- Structure de la table `article`
--
 
CREATE TABLE IF NOT EXISTS `article` (
  `id_article` tinyint(5) NOT NULL AUTO_INCREMENT,
  `reference` varchar(10) NOT NULL,
  `nom_article` varchar(50) NOT NULL,
  `prix_article` decimal(5,2) NOT NULL default '0.00',
  `definition_article` text  NOT NULL,
  `photo_article` varchar(50)  NULL,
  `sscategorie_id` tinyint(5) NOT NULL,
  CONSTRAINT PK_ARTICLE PRIMARY KEY  (`reference`),
  CONSTRAINT FK_ARTICLE_SSCATEGORIE FOREIGN KEY (id_article) REFERENCES sscategorie(id_sscategorie)
) ENGINE = innodb;

Cet exemple reprend ton organisation actuelle.

En ce qui me concerne j'aurais opté pour une autre manière de faire :

CATEGORIE(id_categorie, ..., #id_categorie_parente);
ARTICLE(id_article, ..., #id_categorie)

Il est facil de récupérer toutes les catégories sur X niveaux (une jointure par niveau).

Pour récupérer l'arborescence tu as deux choix :
Soit des parcours récursif qu MySQL ne supporte pas
Soit des parcours intervallaires

[cseb73]

merci de votre aide ,

et en effet je pense qu'il est bon de prendre note
de tes conseils pour une mise a jour de ma structure!


mais le probleme n'en n'etais pas un en fait!

tous simplement le type choisi ======> tinyint(4)

n'autorise pas plus de 8 bit si j'ai bien compris et donc pas

plus de 127 enregistrements.

il a suffit de changer le type des deux table sscategorie et article en int(5)

et c'est reparti!!!.

Merci infiniment tout de meme pour le reste.