Vider la base et insertion des nouvelle en commencant a 1
Résolu
karango
Messages postés
80
Date d'inscription
Statut
Membre
Dernière intervention
-
karango Messages postés 80 Date d'inscription Statut Membre Dernière intervention -
karango Messages postés 80 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
j'ai cree une base de donnee et inserer des lignes dans mes tables, apres j'ai vide la base, maintenant je veux insere des nouvelles linges mais je veux que l'enregestrement recommence a 1 encore. les cle primaires ont de type serial (ID).
Exemple, supposon que je une table eleves( id serial, nom,prenom ect...) avec 10 lingnes,l'ID de la derinier ligne doit etre 10, ou >10 en cas ou j'ai supprime une ou + ligne(s). Donc en vidant cette table et en voulant recommence a faire des nouvelle enregistrement, je ne veux pas qu'elle commence a 11 mais de revenir commencer a 1. Donc ma question est de savoir si ya un moiyen d'eviter sa.
Merci a vous
j'ai cree une base de donnee et inserer des lignes dans mes tables, apres j'ai vide la base, maintenant je veux insere des nouvelles linges mais je veux que l'enregestrement recommence a 1 encore. les cle primaires ont de type serial (ID).
Exemple, supposon que je une table eleves( id serial, nom,prenom ect...) avec 10 lingnes,l'ID de la derinier ligne doit etre 10, ou >10 en cas ou j'ai supprime une ou + ligne(s). Donc en vidant cette table et en voulant recommence a faire des nouvelle enregistrement, je ne veux pas qu'elle commence a 11 mais de revenir commencer a 1. Donc ma question est de savoir si ya un moiyen d'eviter sa.
Merci a vous
A voir également:
- Vider la base et insertion des nouvelle en commencant a 1
- Darkino nouvelle adresse - Guide
- Extreme download nouvelle adresse - Accueil - Outils
- Base de registre - Guide
- Insertion table des matières word - Guide
- Touche insertion clavier - Guide
1 réponse
Bonjour !
Avant d'aller plus loin, quelle est l'utilité de la chose ?
La gestion des id à l'air d'être auto-incrémentale, donc gérée automatiquement par le SGBD.
Même s'il y avait un moyen de customiser ça, sais-tu en quel type de variable est stocké un id ?
Réponse : très généralement un long ou un bigint selon le nommage.
La chose, c'est qu'un long peut correspondre à... 9 223 372 036 854 775 807
valeurs possibles. Autant dire que tu as de la marge.
Le projet informatique au taf est sur une très grosse base (une petite centaine de tables au bas mot) dont certaines tables contiennent 60 000 000 de tuples. Et... ça rentre large. Donc une table d'élèves...
Autrement, tu peux gérer ça, mais il te faut faire du traitement (qui ressemble à ça de manière TRES dégrossie :
INSERT INTO ELEVES ((SELECT MIN(e.ID)
FROM ELEVES e
GROUP BY e.ID
ORDER BY e.ID), tes champs....);
Le souci, c'est les perfs. Pour 1 000 000 d'élèves, tu peux commencer à voir le temps passer ;-)
M'enfin. Tu as là toutes les clés pour avancer. Soit tu fait la méthode sale, soit tu laisses le SGBD gérer à sa sauce.
Voir si cette façon de calculer peut être déportée dans un trigger pour gagner en temps de saisie des ajouts d'éléments ;-)
Bonne journée !
Luc
Les 3 plus grands mensonges du dev : 1. La doc ? On la fera plus tard... 2. Le programme a été testé et ne comporte aucun bug... 3. Les spécifications techniques sont finies...
Avant d'aller plus loin, quelle est l'utilité de la chose ?
La gestion des id à l'air d'être auto-incrémentale, donc gérée automatiquement par le SGBD.
Même s'il y avait un moyen de customiser ça, sais-tu en quel type de variable est stocké un id ?
Réponse : très généralement un long ou un bigint selon le nommage.
La chose, c'est qu'un long peut correspondre à... 9 223 372 036 854 775 807
valeurs possibles. Autant dire que tu as de la marge.
Le projet informatique au taf est sur une très grosse base (une petite centaine de tables au bas mot) dont certaines tables contiennent 60 000 000 de tuples. Et... ça rentre large. Donc une table d'élèves...
Autrement, tu peux gérer ça, mais il te faut faire du traitement (qui ressemble à ça de manière TRES dégrossie :
INSERT INTO ELEVES ((SELECT MIN(e.ID)
FROM ELEVES e
GROUP BY e.ID
ORDER BY e.ID), tes champs....);
Le souci, c'est les perfs. Pour 1 000 000 d'élèves, tu peux commencer à voir le temps passer ;-)
M'enfin. Tu as là toutes les clés pour avancer. Soit tu fait la méthode sale, soit tu laisses le SGBD gérer à sa sauce.
Voir si cette façon de calculer peut être déportée dans un trigger pour gagner en temps de saisie des ajouts d'éléments ;-)
Bonne journée !
Luc
Les 3 plus grands mensonges du dev : 1. La doc ? On la fera plus tard... 2. Le programme a été testé et ne comporte aucun bug... 3. Les spécifications techniques sont finies...
https://stackoverflow.com/questions/7718585/how-to-set-auto-increment-primary-key-in-postgresql
C'est la réponse "edited Nov 5 '12 at 14:36"