Discussion :

[steph49]

bonjour
une question bete je pense mais je rencontre un problème dans ma base avec les AUTO_INCREMENT sur mes ID.
j ai beau dire a la conception de procéder a une AUTO_INCREMENT mais lors d'une requête d insertion dans ne table rien ne ce passe du coup je suis obliger de faire une requête pour lui dire de faire +1 pour l id.

ci-dessous le code d une table

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
 
CREATE TABLE `epreuve` (
  `Id` int(11) NOT NULL AUTO_INCREMENT,
  `Nom_epreuve` varchar(255) NOT NULL,
  `Id_epreuve` tinyint(4) NOT NULL,
  `Id_circuit` tinyint(11) NOT NULL,
  `Date_debut` date NOT NULL,
  `Date_fin` date NOT NULL,
  `Annee` varchar(11) NOT NULL,
  `Nbr_com_mini` varchar(50) NOT NULL,
  `Nbr_com_max` varchar(50) NOT NULL,
  `essai` varchar(10) NOT NULL,
  `Active` varchar(10) NOT NULL
  PRIMARY KEY (Id)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='Table sur les epreuves';

une idée du probleme?

[steph49]

bon ben j ai refait mes table une par une et ca a l air de fonctionner maintenant .

[escartefigue]

Bonjour,

L'auto incrément ne s'applique que dans la table où la colonne est déclarée comme telle, pas dans les tables qui héritent de cette colonne sous forme de clef étrangère.

Par exemple, soit une table des clients ou l'identifiant client (ID_CLI) est déclarée comme PK auto_increment, lors de l'insertion dans cette table, la valeur de la colonne ID_CLI est affectée automatiquement par le moteur du SGBD.
Par contre, dans la table des commandes, la valeur de cette même colonne héritée comme foreign key devra être alimentée lors de l'insert.
On récupèrera la valeur de la table client pour alimenter celle de la table commande.

Quelques remarques :

• le moteur MyISAM est complètement obsolète, il ne gère notamment pas l'intégrité référentielle ! À remplacer par INNODB
• le typage des données est une chose importante, déclarer ce qui ressemble à des montants (ex. Nbr_com_mini) dans une colonne varchar est une aberration, de même, l'année dans du varchar(11) n'a aucun intérêt, à remplacer par du char(4) puisqu'aucun calcul ne sera appliqué sur cette colonne.

[SQLpro]

... l'année dans du varchar(11) n'a aucun intérêt, à remplacer par du char(4) puisqu'aucun calcul ne sera appliqué sur cette colonne.

D'abord je pense qu'il à raison de prévoir large.... Il me semble que pouvoir mettre l'an 99 999 999 999 permettra d'éviter le bug de l'an 10 000 et les autres...

En revanche, des calculs sur des années, ça existe.... Dont le mettre en smallint par exemple.

A +

[pier.antoine]

Frédéric

Ta réponse laisse entendre qu'on peut ne pas utiliser les fonctions "Date" proposées en SQL ?

Dans quel cas, il serait plus intéressant de faire des calculs que d'utiliser ces fonctions ?

Merci d'avance

Pierre

[SQLpro]

dans tous les cas OUI... Pour des raisons de perf...

C'est aussi pour cela que dans les BI (cube et autres) on ajoute une table de calendrier afin d'éviter trop d'appel aux fonctions.

RAPPEL : x appel de fonctions => x fois le temps d'exécution de la fonction, même si les paramètres d'entrée et le résultat est le même.. En revanche dans une jointure si les données sont les mêmes, le résultat sera le même donc, le moteur ne fait qu'une seule fois l'opération... En sus s'il y a des index, du parallélisme et de la compression... C'est le bonheur assuré !

A +

[pier.antoine]

Merci pour l'info

A plus tard

Pierre