Je dois gerer une base de données !
Je fais mes requetes à partir d'une page jsp
voila mon pb :
Lorsque je supprime une ligne, comment remettre les serial a jour ?
Car du coup ca fait des trous ds ma table et qd je veux ajouter une données, il l'ajoute la ou il trouve un trou, mais pas avec le bon serial

Si je supprime la ligne 4, puis j'ajoute une ligne (sachant que le serial de ma dernière ligne est 11)


ex :

1 gdgdg
2 gdfgdfg
3 tret
12 rzer
5 mkmkmk
6 sfg
7 rferg
8 liol
9 gedsrg
10 hrth
11 jlui


merci de votre aide !

je suis pas tres sur d'avoir bien compris ton soucis... tu veux que qd tu supprime un enreg de ta base, les donnees restent indexees dans le meme ordre, c'est ca ? en refaisant les index ? genre le 5 devient le 4, le 6 devient le 5, etc...
est ce que tes num de lignes sont reels, autrement dit, as tu un index sur ta table ?

Le 23/07/2002 à 11h16 , grabber a écrit:
je suis pas tres sur d'avoir bien compris ton soucis... tu veux que qd tu supprime un enreg de ta base, les donnees restent indexees dans le meme ordre, c'est ca ? en refaisant les index ? genre le 5 devient le 4, le 6 devient le 5, etc...
est ce que tes num de lignes sont reels, autrement dit, as tu un index sur ta table ?


Voila c tout a fait ca mon souci !
Et non j'ai pas d'index sur ma table
Comment ca marche et a koi ca sert les index ?
Ca peut m'aider pour mon pb ?


merci d'avance

Si je comprends bien, il aimerait pouvoir réutiliser l'index de l'enregistrement qu'il vient de supprimer :-?

CAD, je supprime l'enregistrement index='5' valeur='mavaleur1'
et il aimerait faire un nouvel insert avec un index = '5' valeur='mavaleur2'

Or à mon sens, ça me semble impossible car c'est là l'interêt de l'index auto-incrémentiel... il est auto-incrémentiel
donc unique !

Le 23/07/2002 à 11h33 , noody a écrit:
Si je comprends bien, il aimerait pouvoir réutiliser l'index de l'enregistrement qu'il vient de supprimer :-?

CAD, je supprime l'enregistrement index='5' valeur='mavaleur1'
et il aimerait faire un nouvel insert avec un index = '5' valeur='mavaleur2'

Or à mon sens, ça me semble impossible car c'est là l'interêt de l'index auto-incrémentiel... il est auto-incrémentiel
donc unique !



Je comprend pas trop ce que tu dit mais bon !
Mettons que j'ai 12 enregistrement :
je supprime l'enrigistrement correspondant au serial n. 5
Je ne veux pas me retrouver avec un trou ds ma table,et qu'il m'insere une ligne avec un serial n. 12,
car a force de supprimer et ajouter , je vais me retrouver avec des serial allant jusqu'a perpettes oies !

Help ! Help !

ben wi, mais avec un index auto-incrémenté tu auras du mal

ou alors faut pas auto-incrémenté l'index, et recherché à chaque fois le premier index manquant et y insérer ta ligne

Je comprend pas trop ce que tu dit mais bon !
Mettons que j'ai 12 enregistrement :
je supprime l'enrigistrement correspondant au serial n. 5
Je ne veux pas me retrouver avec un trou ds ma table,et qu'il m'insere une ligne avec un serial n. 12,
car a force de supprimer et ajouter , je vais me retrouver avec des serial allant jusqu'a perpettes oies !


Oui, mais je crains que tu n'aies pas le choix...
Car tu dois avoir ton index (serial si tu préfères) qui s'auto-incrémente (+1) à chaque fois que tu fais un INSERT dans ta table.

Le seul moyen de contourner ton pb serait effectivement de supprimer cette auto-incrémentation.

Mais ça n'est pas très pratique de modifier les serials de tous tes enregistrements à chaque fois que tu supprimes un enregistrement, car ça va être bcp trop lourd au niveau traitement

je suis clair là ? non ?

Le 23/07/2002 à 12h04 , Erel69 a écrit:
ben wi, mais avec un index auto-incrémenté tu auras du mal

ou alors faut pas auto-incrémenté l'index, et recherché à chaque fois le premier index manquant et y insérer ta ligne



ce qui n'est pas très propre selon moi...
Enfin tout dépend de l'utilisation et du volume de données à gérer !

Le 23/07/2002 à 12h04 , noody a écrit:

Je comprend pas trop ce que tu dit mais bon !
Mettons que j'ai 12 enregistrement :
je supprime l'enrigistrement correspondant au serial n. 5
Je ne veux pas me retrouver avec un trou ds ma table,et qu'il m'insere une ligne avec un serial n. 12,
car a force de supprimer et ajouter , je vais me retrouver avec des serial allant jusqu'a perpettes oies !


Oui, mais je crains que tu n'aies pas le choix...
Car tu dois avoir ton index (serial si tu préfères) qui s'auto-incrémente (+1) à chaque fois que tu fais un INSERT dans ta table.

Le seul moyen de contourner ton pb serait effectivement de supprimer cette auto-incrémentation.

Mais ça n'est pas très pratique de modifier les serials de tous tes enregistrements à chaque fois que tu supprimes un enregistrement, car ça va être bcp trop lourd au niveau traitement

je suis clair là ? non ?





Ouais la c parfait ! lol

Donc en fait y faut pas que j'auto incrémente mes index c ca ?
Y faudrait que je repere ou sont les vides, que je chope le numero de l'index précédent et que je l'insere après c ca ?
Qqun peut m'aider a faire ca (un pro du SQL ca doit se trouver), le SQL ca me gave :gun1: ! en plus c qu'une toute petite partie de mon projet, alors j'ai pas trop envie de chercher !

help ! help !

Ben , ca pas vraiment une grosse base mais ca pourrait le devenir, alors je sais pas qu'elle sont les soucis que je peut rencontrer ! :-? :-?

mais tu comprend que pour une table que j'appellle typeFichier par exemple a force de faire des ajouter supprimer j'ai pas envie de me retrouver avec ca :

1 unl
2 sql
1245 txt
4 jar
4581225 java
6 war
...
...
...


tu vois ce que je veux dire ?

Le 23/07/2002 à 12h15 , kizou38 a écrit:
Ben , ca pas vraiment une grosse base mais ca pourrait le devenir, alors je sais pas qu'elle sont les soucis que je peut rencontrer ! :-? :-?

mais tu comprend que pour une table que j'appellle typeFichier par exemple a force de faire des ajouter supprimer j'ai pas envie de me retrouver avec ca :

1 unl
2 sql
1245 txt
4 jar
4581225 java
6 war
...
...
...


tu vois ce que je veux dire ?


Je vois bien mais en quoi cela te gêne ?
L'auto-incrémént te permet d'être sûr d'avoir un enregistrement unique.
Ca évite de te retrouver avec erreurs au moment où tu vas faire des traitements sur ta table (UPDATE, DELETE, INSERT)

ben wi, l'auto-increment c'est très bien et ca gèen pas

sinon à chaque suppréssion va falloir que tu passe par un tassage, c'est un peu lourd

Pour répondre à ta question je dirais que c'est pas un problème de SQL mais un problème de configuration / création de ta table et ça amha ça dépend du sgdb utilisé. Sur la plupard des sgbd tu peux gérer tes indexs (ou numéro d'enregistrement) comme tu veux et désactivant l'auto-incrémentation et en affectant toi-même une valeur quand tu ajoute un enregistrement. Par contre il faut faire attention si ce numéro sert de référence dans une relation avec une autre table. Pour te dire après comment le gérer toi-même il faudrait un peu plus d'infos: structures de tes tables (pour les relations) sgbd utilisé, fréquence de chaque type de transaction (ajout, suppression)...
Après rien ne t'empêche de laisser le numéro auto-incrémental pour la gestion interne du sgbd et d'ajouter une colonne avec un numéro d'ordre que tu gére toi-même si tu as besoin de numéros qui se suivent pour l'aspect fonctionnel. Comme ça tu n'as pas besoin de prendre en compte les problèmes de relation.

Le 23/07/2002 à 13h51 , jeunesse_sonique a écrit:
Pour répondre à ta question je dirais que c'est pas un problème de SQL mais un problème de configuration / création de ta table et ça amha ça dépend du sgdb utilisé. Sur la plupard des sgbd tu peux gérer tes indexs (ou numéro d'enregistrement) comme tu veux et désactivant l'auto-incrémentation et en affectant toi-même une valeur quand tu ajoute un enregistrement. Par contre il faut faire attention si ce numéro sert de référence dans une relation avec une autre table. Pour te dire après comment le gérer toi-même il faudrait un peu plus d'infos: structures de tes tables (pour les relations) sgbd utilisé, fréquence de chaque type de transaction (ajout, suppression)...
Après rien ne t'empêche de laisser le numéro auto-incrémental pour la gestion interne du sgbd et d'ajouter une colonne avec un numéro d'ordre que tu gére toi-même si tu as besoin de numéros qui se suivent pour l'aspect fonctionnel. Comme ça tu n'as pas besoin de prendre en compte les problèmes de relation.



Ouep, chui d'accord
Le but du jeu, c'est de récupérer tous les enregistrements de ta table et de les afficher dans l'ordre où tu les as créé ?
Si tel est le cas, tu peux appliquer la méthode de jeunesse_sonique qui consiste à crée une colonne 'ordre' que tu gères indépendemment de tes index.
Et selon moi, c + propre et + sûr :yep:

Le 23/07/2002 à 12h15 , kizou38 a écrit:
mais tu comprend que pour une table que j'appellle typeFichier par exemple a force de faire des ajouter supprimer j'ai pas envie de me retrouver avec ca :

1 unl
2 sql
1245 txt
4 jar
4581225 java
6 war
tu vois ce que je veux dire ?

Tu te retrouvera jamais avec ça, l'ordre reste croissant, la seule chose c'est qu'il peut y avoir des trous:
1 unl
2 sql
4 jar
6 war
1245 txt
4581225 java
et ça voudrait dire que tu as fait 4579980 ajout-suppressions entre tes deux derniers enregistrements.

tu programmes en kel langage ???
c pas bien dur, il suffit de balayer ta table sequentiellement en traitant chaque index pour verifier que l'index X = (index X-1) +1
quand la condition n'est pas verifiee, tu as trouve un trou dans ta table :wink:
le probleme de cette methode est que tu perds tout l'interet de la base car ton traitement risque d'etre VRAIMENT TRES LONG suivant la taille de ta table. c'est comme si tu utilisait un fichier texte pour stocker tes infos sequentiellement c'est un peu du bricolage, et comme les autres, je pense pas que ce soit top comme solution, surtout si c note derriere... je doute que t une bonne note :wink:
mon conseil, sert toi des index, qui t'apporteront souplesse et rigueur (eviter les doublons d'index). tu sais peut etre pas faire pour l'instant, mais des que tu l'auras fait une fois, tu comprendras vite la difference de perf

n'hesites pas a reposter avec les infos qu'on te demande pour aller plus loin :wink:

@+


Le 23/07/2002 à 12h12 , kizou38 a écrit:

Le 23/07/2002 à 12h04 , noody a écrit:

Je comprend pas trop ce que tu dit mais bon !
Mettons que j'ai 12 enregistrement :
je supprime l'enrigistrement correspondant au serial n. 5
Je ne veux pas me retrouver avec un trou ds ma table,et qu'il m'insere une ligne avec un serial n. 12,
car a force de supprimer et ajouter , je vais me retrouver avec des serial allant jusqu'a perpettes oies !


Oui, mais je crains que tu n'aies pas le choix...
Car tu dois avoir ton index (serial si tu préfères) qui s'auto-incrémente (+1) à chaque fois que tu fais un INSERT dans ta table.

Le seul moyen de contourner ton pb serait effectivement de supprimer cette auto-incrémentation.

Mais ça n'est pas très pratique de modifier les serials de tous tes enregistrements à chaque fois que tu supprimes un enregistrement, car ça va être bcp trop lourd au niveau traitement

je suis clair là ? non ?





Ouais la c parfait ! lol

Donc en fait y faut pas que j'auto incrémente mes index c ca ?
Y faudrait que je repere ou sont les vides, que je chope le numero de l'index précédent et que je l'insere après c ca ?
Qqun peut m'aider a faire ca (un pro du SQL ca doit se trouver), le SQL ca me gave :gun1: ! en plus c qu'une toute petite partie de mon projet, alors j'ai pas trop envie de chercher !

help ! help !

Le 23/07/2002 à 13h54 , noody a écrit:

Le 23/07/2002 à 13h51 , jeunesse_sonique a écrit:
Pour répondre à ta question je dirais que c'est pas un problème de SQL mais un problème de configuration / création de ta table et ça amha ça dépend du sgdb utilisé. Sur la plupard des sgbd tu peux gérer tes indexs (ou numéro d'enregistrement) comme tu veux et désactivant l'auto-incrémentation et en affectant toi-même une valeur quand tu ajoute un enregistrement. Par contre il faut faire attention si ce numéro sert de référence dans une relation avec une autre table. Pour te dire après comment le gérer toi-même il faudrait un peu plus d'infos: structures de tes tables (pour les relations) sgbd utilisé, fréquence de chaque type de transaction (ajout, suppression)...
Après rien ne t'empêche de laisser le numéro auto-incrémental pour la gestion interne du sgbd et d'ajouter une colonne avec un numéro d'ordre que tu gére toi-même si tu as besoin de numéros qui se suivent pour l'aspect fonctionnel. Comme ça tu n'as pas besoin de prendre en compte les problèmes de relation.



Ouep, chui d'accord
Le but du jeu, c'est de récupérer tous les enregistrements de ta table et de les afficher dans l'ordre où tu les as créé ?
Si tel est le cas, tu peux appliquer la méthode de jeunesse_sonique qui consiste à crée une colonne 'ordre' que tu gères indépendemment de tes index.
Et selon moi, c + propre et + sûr :yep:

Ya même plus simple, là c'était si tu voulais absolument avoir les numéros dans la base. Sinon ce que l'on fait d'habitude c'est que les numéros tu les gére au niveau de ta couche soft (jsp dans ton cas). Par exemple tu fais un select avec un order by sur le numéro d'index (non tassé) et au fur et à mesure que tu lis tes enregistrements tu les renumérotes, en puis tu gére ton numéro d'index dans des données cachées (par exemple une colonne invisible dans un controle de tableau ou une zone de texte invisible...).

oki, merci les gars pour toute ces infos,
je vais potasser un peu ca puis si jé des question je vous fais signe ! :wink:

Et croyais-moi, etre en stage tout l'été
c'est :gun1: :gun1: :gun1:

Le 23/07/2002 à 14h35 , kizou38 a écrit:
oki, merci les gars pour toute ces infos,
je vais potasser un peu ca puis si jé des question je vous fais signe ! :wink:

Et croyais-moi, etre en stage tout l'été
c'est :gun1: :gun1: :gun1:

On est nombreux à être passés par là mais quand tu bosses t'as encore moins de vacances alors ne te plains pas trop. :wink:

Le 23/07/2002 à 17h06 , jeunesse_sonique a écrit:

Le 23/07/2002 à 14h35 , kizou38 a écrit:
oki, merci les gars pour toute ces infos,
je vais potasser un peu ca puis si jé des question je vous fais signe ! :wink:

Et croyais-moi, etre en stage tout l'été
c'est :gun1: :gun1: :gun1:

On est nombreux à être passés par là mais quand tu bosses t'as encore moins de vacances alors ne te plains pas trop. :wink:



Ah ca je suis pas sur, 2 semaine de vacances en un an c pas énorme !
Bon c vrai que pd l'année la vie etudiante c pas ce qu'il y a de plus stressant !

Vive les vacances et faites la fetes !!