Par rapport à AUTO_INCREMENT

par **jilie** » 18 oct. 2011, 15:28

merci a vous !

par **macgawel** » 18 oct. 2011, 09:30

Mais sélectionner les 10 premiers implique un tri à cause de "premier"

+ 1.

Avant de sortir les N premiers articles, il faut bien les trier sur un critère.
Indice : La date de création est un critère

=> Si tu veux sortir les N premiers articles, il faut définir le critère de tri (date de création, nom de l'article, âge du capitaine). Ce critère de tri doit être intégré dans ta base (ça doit être un champ de ta table).
Si tu veux faire les choses correctement tu ne peux pas te baser sur l'ID, qui n'a pas de sens (d'autant moins s'il est auto-incrémenté)...

par **Mazarini** » 18 oct. 2011, 08:42

Regardes du coté de LIMIT dans les ordres SQL.
Genre select * from TaTable limit 10 ou select * from TaTable limit 1,10

Mais sélectionner les 10 premiers implique un tri à cause de "premier"

par **jilie** » 18 oct. 2011, 00:38

Non je ne disait pas ça pour le tri mais pour la séléction des 10 premier articles par exemple, comment remmetre les identifiants dans l'odre croissant sans trou (exemple 1.2.3.4.5) aprés avoir suprimer l'identifiant 2 par exemple ?

par **macgawel** » 17 oct. 2011, 16:44

Par exemple si il avait 6 identificateur et qu'on suprime le 2éme puis qu'on veux remettre tout les id dans l'ordre (1.2.3.4.5) comment faire ?
Est-ce qu'il y a une fonction qui permet de le faire , ou on est obligé de le faire manuellement (sachant que c'est pas conseillé) ?

Tu veux les remettre dans quel ordre au juste ?

Dans une Base de données relationnelle, un identifiant ne doit pas être significatif.
En clair, si tu n'as plus l'Id 2, ce n'est pas grave. Pareil, l'ordre dans la BDD n'a pas d'importance, c'est le système qui gère.
Et pour le tri, tu ne le fais pas sur l'identifiant mais sur une valeur significative (le nom par exemple) ou tu n'en fais pas...

par **jilie** » 17 oct. 2011, 15:07

Il est même déconseillé d'aller écrire/modifier manuellement dans un champ en auto-increment....

C'est très bien au contraire à condition de ne pas modifier sa gestion en modifiant des clés calculées automatiquement ou en les forçant. Mais bon, il n'y a pas d'intérêt à faire ce genre de manipulations.

Par exemple si il avait 6 identificateur et qu'on suprime le 2éme puis qu'on veux remettre tout les id dans l'ordre (1.2.3.4.5) comment faire ?
Est-ce qu'il y a une fonction qui permet de le faire , ou on est obligé de le faire manuellement (sachant que c'est pas conseillé) ?

par **Mazarini** » 17 oct. 2011, 14:22

Je me suis surement mal exprimé, ce qui est kamikaze, c'est d'utiliser l'auto-incrément partiellement.

C'est très bien au contraire à condition de ne pas modifier sa gestion en modifiant des clés calculées automatiquement ou en les forçant. Mais bon, il n'y a pas d'intérêt à faire ce genre de manipulations.

par **macgawel** » 17 oct. 2011, 14:17

non, il ne faut pas être kamikaze pour utiliser l'auto-increment...

En fait, il faut être un peu kamikaze pour modifier la valeur d'une clé avec un auto-incrément

pour faire ça manuelement faux récupérer l'id du dérnier enregistrement et pour cela il faux compter le nombre de ligne qu'il y a dans la table puis rajouter 1 mais
sa fait des requetes en plus donc sa ralenti le script nan ?

On ne fait pas manuellement !
C'est l'intérêt de l'auto-increment : le système gère tout seul l'incrémentation de la clé, tu n'as pas à t'en soucier. Il est même déconseillé d'aller écrire/modifier manuellement dans un champ en auto-increment...

par **jilie** » 17 oct. 2011, 14:10

ok daccord mais je comprend toujours pourquoi c'est kamikaze d'utiliser l'auto_increment peut etre parce que je débute mais si tu peux me dire pourquoi

par **Mazarini** » 17 oct. 2011, 12:08

Lorsque l'on fait ca manuellement, on peut utiliser une table qui contient un compteur que l'on incrémente manuellement via une commande SQL. C'est un des intérêts de Mysql de nous soulager de cette gestion.

Compter les enregistrements, n'est pas correct à cause des suppressions d'enregistrements.

par **jilie** » 17 oct. 2011, 11:19

pour faire ça manuelement faux récupérer l'id du dérnier enregistrement et pour cela il faux compter le nombre de ligne qu'il y a dans la table puis rajouter 1 mais
sa fait des requetes en plus donc sa ralenti le script nan ?

par **Mazarini** » 17 oct. 2011, 09:56

En fait, il faut être un peu kamikaze pour modifier la valeur d'une clé avec un auto-incrément (modification de la base de calcul ou d'une clé).

Une clé unique suffit, l'auto-incrément facilite juste le calcul de cette clé en permettant de ne pas s'en occuper. Dans d'autre système que MySQL, on est obligé de gérer manuellement un compteur pour avoir cette clé ou on utilise un timestamp.

par **jilie** » 17 oct. 2011, 09:38

ok merci

par **Mazarini** » 17 oct. 2011, 09:22

Bonjour,

C'est surtout une clé unique qui permet de garantir l'unicité. L'auto-incrément permet de laisser calculer une clé qui s'incrémente, mais rien n'empêche de modifier la valeur qui est incrémentée ou de spécifier une valeur dans un insert. L'auto-incrément permet juste le calcul d'une valeur par défaut.
L'unicité via l'auto-incrent est assuré si :
- on ne modifie pas la valeur sur laquelle repose le calcul
- on insere jamais en forcant la valeur et on ne modifie pas la valeur

par **jilie** » 17 oct. 2011, 09:14

merci pour la double information

Par rapport à AUTO_INCREMENT

Répondre

Étendre la vue Revue du sujet : Par rapport à AUTO_INCREMENT

Re: Par rapport à AUTO_INCREMENT

Re: Par rapport à AUTO_INCREMENT

Re: Par rapport à AUTO_INCREMENT

Re: Par rapport à AUTO_INCREMENT

Re: Par rapport à AUTO_INCREMENT

Re: Par rapport à AUTO_INCREMENT

Re: Par rapport à AUTO_INCREMENT

Re: Par rapport à AUTO_INCREMENT

Re: Par rapport à AUTO_INCREMENT

Re: Par rapport à AUTO_INCREMENT

Re: Par rapport à AUTO_INCREMENT

Re: Par rapport à AUTO_INCREMENT

Re: Par rapport à AUTO_INCREMENT

Re: Par rapport à AUTO_INCREMENT

Re: Par rapport à AUTO_INCREMENT