Version imprimable
bonjour,
Toujours moi j'aimerais que vous m'éclairiez sur les séquences.
Voila je voudrais savoir si j'ai plusieurs tables avec une séquence et sur une table je fais plusieurs insert et sur une table(n-1) toujours vierge:mouarf: aucune chance d'avoir le fameux 1?????
si c'est vrai donc faut prévoir autant de tables que de séquences???:!::cfou:
Deux méthodes :Bref, c'est au choix du DBA...
- Tu créé une séquence par table afin d'avoir une abstraction entre les séquences elles-même et une unicité suivie des tes lignes.
- Tu créé une séquence que tu partage entre plusieurs tables. Mais attention lors de multiples inserts très rapides et continuels entre plusieurs tables par plusieurs clients la consultation de la séquence bien que non incorporé à la session peut être un petit goulot d'étranglement (Rare mais pas impossible).
:D
En tout cas :
- Ne pas sous estimer l'impact de l'option CACHE lors de la création de la séquence. Dans le cas de bases à forte volatilité, il n'est pas inutile d'estimer et de spécifier le nombre de références utilisée par tranche de N secondes par tous les clients confondus (Généralement 5 secondes sont pas mal).
- Il est souvent judicieux d'utiliser un TRIGGER BEFORE INSERT pour assigner un numéro de séquence en PL/SQL de façon automatisée à chaque nouvelle ligne. Cela évite au client de demander des séquences inutilisées et surtout de diminuer les allez/retour inutiles entre la base et celui-ci.
ok j'ai compris ce la dit selon la structure de de la création de la séquence c'est pas spécifier comme quoi serai pour plusieurs tableCitation:
Envoyé par philcero
donc ce qui veux une table qui reçu une incrementation (valeur) =9
l'autre table qui a besoin d'une valeur lors de l'incrementation =3 sera pas possible parce que le compteur est déjà arrivé a 9
pour le trigqer j'ai pas compris son utilité car il intervient avant l'insertion puis récupère la valeur current du séquence a quoi sert on peut passer par sequence.next;ou bien vous voulez dire lors de l'insertion au lieu de mettre dans la requête le champ id par exemple tu mets son incrementation dans un trigger
donc il faut autant de trigger que de table que de sequences.
excuse moi si je détails car j'essaye de comprendre
L'idée d'avoir un TRIGGER pour chaque table qui se sert d'une séquence pour créer ta clef primaire revient à remonter au niveau de la base la gestion de celle-ci. Donc pas besoin d'implémenter dans ton code la récupération d'une séquence que tu attribue ensuite à un INSERT et qui alourdi inutilement le code. Tu peux ainsi concentrer ton code sur la logique métier et tu sécurise ton application.
Pour le nombre de séquences à implémenter, comme je l'ai déjà dit, c'est à chacun sa méthode. Les puristes prôneront la clarté UNE TABLE / UNE SEQUENCE alors que les opérationnels prôneront l'efficacité UNE SEQUENCE / TOUT LE RESTE !
ok ça passe pour le trigger:mouarf:
juste pour le truc des opérationnels:oops:
comment ils vont procéder(sequence/all tables)
si on prends une table ca serai
c pas evident!!!!!!!!!!!!!Code:
2
3
4
5
6
7
8
ya pas une solution entre les operationnells et les pursistes?
Là où tu pêche c'est que tu fais un lien dans ton esprit entre la clef (Suite numérique) et le contenu des lignes (Les données de production).
Hors les deux sont totalement dissociables, la clef n'est qu'un pointeur vers un enregistrement. Que celle-ci soit une jolie suite logique ou bien une série de séquences incompréhensible n'a absolument aucune importance vu que quelque part celle-ci fait partie de la logique de la base et non de la logique applicative. elle reste invisible pour le client (Une liste présentant de façon visuelle les clefs des enregistrements est une très mauvaise chose).
ok je vois
merci pour la vue perspective que tu m'as offert c'est que je pas vu les choses comme ca
merci