Discussion :

[ninikkhuet]

Bonjour,

toutes les requêtes portant sur une table de ma base de données sont lentes et je pense qe c'est dû au fait qu'il y a beaucoup trop de données dedans mais n'en suis pas sûr.

Est-ce que vous pourriez jeter un coup d'oeil à la pièce jointe et me dire ce que vous en pensez ? C'est une copie d'écran de l'onglet "Information" de ma table dans Toad.

Merci.

[CinePhil]

745 008 lignes, c'est pas mal mais j'ai déjà travaillé avec des tables presque dix fois plus grosses.

1,6 Go de données c'est pas mal non plus mais ce n'est pas impossible à traiter.
29 Mo d'index, ce n'est peut-être pas beaucoup par rapport à la taille de la table.

Il faudrait nous donner le SHOW CREATE TABLE de cette table.

[ninikkhuet]

le 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
 
CREATE TABLE `table` (
  `operation_type` varchar(8) NOT NULL default '',
  `site` varchar(50) default NULL,
  `site_code` varchar(20) default NULL,
  `dept` varchar(100) default NULL,
  `dept_code` varchar(20) default NULL,
  `n_client` varchar(10) NOT NULL default '0',
  `ref_option` varchar(50) NOT NULL,
  `code` char(3) NOT NULL default '',
  `qte` tinyint(2) NOT NULL default '1',
  `mtht` decimal(12,3) NOT NULL default '0.000',
  `tva` decimal(4,2) default '0.00',
  `ident_cc2` varchar(8) NOT NULL default '',
  `date_enr` datetime NOT NULL default '1000-01-01 00:00:00',
  `cc_init` varchar(100) NOT NULL,
  `histo_valideur` longtext NOT NULL,
  `dernier_valideur` varchar(10) NOT NULL default 'nonvalidé',
  `date_valideur` datetime default NULL,
  `ident_integrateur` varchar(20) NOT NULL default '',
  `date_integration` datetime default NULL,
  `valide` tinyint(1) unsigned zerofill NOT NULL default '0',
  `refusN4` tinyint(4) NOT NULL default '0',
  `integre` tinyint(1) unsigned zerofill NOT NULL default '0',
  `rejete` tinyint(1) unsigned zerofill NOT NULL default '0',
  `plateforme` varchar(15) NOT NULL default '',
  `ref_lot` varchar(20) NOT NULL default '0',
  `ocv04` longtext NOT NULL,
  PRIMARY KEY  (`n_client`,`date_enr`),
  KEY `date1` (`date_valideur`),
  KEY `ident_cc2` (`ident_cc2`),
  KEY `site` (`site`),
  KEY `date2` (`date_enr`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

[overider]

salut.


Je pense qu'il y a un souci de conception au niveau de ta base. J'espere que tu n'as rien codé avec cette table.

Mettre tout les données dans une seule et même table ne permets pas vraiment d'exploiter comme il faut tes données.

Il va falloir éclater cette table nommé "table" en facilement 4 a 5 tables.

a premiere vue, je vois bien: "client", "service", "contact", "facture" ou "facturation" ... puis apres si tu veux aller plus loin article. pour la facturation tu fais une relation n:n avec contact et comme champ date, statut ect.


aprés j'y ai pas passé beaucoup de temps. et je suis pas trés bon en modelisation.


bonne chance.

[CinePhil]

Effectivement, il y a des choses à revoir !

On peut savoir de quoi il s'agit parce que les libellés des colonnes ne sont pas hyper clairs et peuvent être interprétés de plusieurs façons.

1) Ne pas appeler une table 'table'
Les tables et les colonnes ne doivent pas être appelés d'un mot du langage SQL. Ca peut provoquer des erreurs.

2) La clé primaire composée de deux colonnes laisse à penser qu'il s'agit d'une table issue d'une association porteuse de données.
Il s'agit d'enregistrements relatifs à des clients ?
Des enregistrements de quoi ?
De plus, cette clé primaire, composée d'une colonne de type VARCHAR(10) et d'une de type DATETIME, n'est pas optimale.
Une bonne clé issue d'une entité du MCD est de type INTEGER.
Par voie de conséquence, les clés des tables associatives sont composées de clés étrangères de même type que les identifiants auxquels elles font référence et seront aussi de type entier. Il est toutefois possible qu'une colonne de type DATE participe à la clé primaire d'une table associative, comme cela semble être le cas ici.

3) Si j'en crois son nom, la colonne operation_type est censée contenir un type d'opération. Là encore, il devrait s'agir d'une clé étrangère faisant référence à l'identifiant de type entier d'une table des types d'opération.

4) Les colonnes 'site' et 'site_code' représentent probablement la même donnée. Il y a donc doubon d'information dans la table. Il devrait y avoir une table des sites et ici une clé étrangère faisant référence à l'identifiant du site.

J'espère que vous avez compris le principe.

Modélisez vos données en utilisant par exemple la méthode Merise et normalisez au maximum votre modèle de données.

Nous pourrons vous y aider dans le forum Schéma.

Bon courage !

[ninikkhuet]

Bonjour,

merci pour ces réponses, je vais revoir entièrement cette table, je me disais bien qu'il y avait un gros souci

Par curiosité j'aimerais bien savoir comment on sait qu'il n'y a quasiment plus de places dans une table, et surtout qu'est-ce qu'on fait dans ces cas-là ? Je pense que ça ne doit pas arriver souvent mais j'aimerais quand même connaître la solution..

[CinePhil]

On peut stocker des dizaines de millions de lignes sans problème dans une table. Je pense que tu as le temps de voir venir !