Insert massif et identity

Citation:

---

Envoyé par elsuket

"A la main" : je ne suis pas sûr que cela fasse que l'application qui va utiliser la base de données soit fiable ensuite ;)

Et en faisant un MAX(colonne) + 1, il y aura quand même des "trous", et des performances médiocres.

---

euh... si je peux me permettre c'est complètement faux!! Tu as déjà essayé sur un site de production avec plusieurs milliers de user simultanés? Moi oui! et ça marche très bien!

Evidemment ce n'est pas ce que je recommande, et j'essaye de l'éviter le plus possible. Mais si tu VEUX absolument le faire tu peux... CQFD

En ce qui concerne la "fiabilité", cela dépend du "à la main"... si le "à la main" est bien fait alors ça pose pas de problème.

Encore une fois c'est à éviter bien entendu...

Citation:

---

Envoyé par elsuket

l'utilisateur se fiche éperdument que les utilisateurs aient des identifiants qui ne se suivent pas

---

ça aussi justement, tu n'en sais rien.

Bonjour,

+1 pour les propositions de elsuket :zoubi:

Code:

---

1 2 3 4 5 6 7

CREATE TABLE users( idper int identity(1,1) NOT NULL PRIMARY KEY, nom varchar (20) NOT NULL, prenom varchar (20) NOT NULL, login varchar (20) NOT NULL, motpasse varchar (20) NOT NULL, )

---

Citation:

---

Envoyé par elsuket
l'utilisateur se fiche éperdument que les utilisateurs aient des identifiants qui ne se suivent pas.

---

Citation:

---

Envoyé par the eye
ça aussi justement, tu n'en sais rien.

---

Depuis quand un utilisateur voit t'il un identifiant manifestement technique ?

@+

Citation:

---

Si je peux me permettre c'est complètement faux!!

---

Prouve que c'est faux.

Heureusement que agemis est là ;)

Citation:

---

Mais si tu VEUX absolument le faire tu peux... CQFD

---

Effectivement, mais je ne souhaite pas faire n'importe quoi ...
Le but de ce forum n'est pas de fournir une réponse ultra-rapide à une question ;)

Citation:

---

En ce qui concerne la "fiabilité", cela dépend du "à la main"... si le "à la main" est bien fait alors ça pose pas de problème.

---

Le but de l'informatique étant d'automatiser les tâches, tu reviens un peu à l'âge de pierre en disant cela.
Faire du "manuel" dans un environnement de production ne peut pas permettre de garantir la qualité, surtout quand on est à plusieurs à modifier des valeurs manuellement ...

Citation:

---

Tu as déjà essayé sur un site de production avec plusieurs milliers de user simultanés?

---

Non, parce que je reste persuadé que c'est contre-performant.
As-tu essayé de faire cela sur une table qui comporte 100 millions de lignes ?
Je doute qu'en environnement OLTP ce soit viable ...

@++ ;)

Citation:

---

Envoyé par agemis31

Depuis quand un utilisateur voit t'il un identifiant manifestement technique ?

---

Qu'est-ce qui t'empêche de l'afficher dans un tableau?

En fait vous confondez faisabilité et bonne pratique... la question ici était : est-ce possible?

La réponse est donc oui!

Et IDENTITY ne permet pas d'avoir des identifiants sans trou de séquence, donc IDENTITY N'EST PAS LA SOLUTION AU PROBLEME!

Ensuite, à la question faut-il mieux gérer ces tables avec une colonne IDENTITY, la réponse est oui!... mais c'est la question qui est hors sujet

Dernièrement, le fait de faire un MAX +1 sur une colonne de type int de type PRIMAREY KEY n'est pas du tout catastrophique pour les perfs (faite une étude du nb d'io et de la charge CPU d'une telle requête si vous en doutez...)

Citation:

---

Qu'est-ce qui t'empêche de l'afficher dans un tableau?

---

De vouloir faire une application propre ...

Citation:

---

Dernièrement, le fait de faire un MAX +1 sur une colonne de type int de type PRIMAREY KEY n'est pas du tout catastrophique pour les perfs (faite une étude du nb d'io et de la charge CPU d'une telle requête si vous en doutez...)

---

C'est vrai, ça doit en faire moins que de laisser le soin à SQL Server de calculer nouvelle valeur d'IDENTITY (opérateur COMPUTE SCALAR) ...

Allez bon boulot ;)

Citation:

---

Envoyé par the eye
Qu'est-ce qui t'empêche de l'afficher dans un tableau?

---

Rien. En te paraphrasant on peut tout faire si on le veut.

Citation:

---

En fait vous confondez faisabilité et bonne pratique... la question ici était : est-ce possible?

La réponse est donc oui!

---

Je dirais plutot que parfois faisabilité à tout prix rime avec prise de tête.

Dans une optique "est ce possible", il est clair que l'IDENTITY n'est pas la solution.

Néanmois, puisque tu parles d'expérience, j'ai déja eu affaire à quelques "responsables" qui voulaient éviter à tout prix les trous dans les séquences, la plupart du temps pour des raisons purement idéologiques.
Il faut que je relise la discussion en entier, mais il me semble que faire un max + 1 ne résoud pas ce problème.

Cordialement,

Citation:

---

Envoyé par agemis31

Rien. En te paraphrasant on peut tout faire si on le veut.,

---

Oui, il suffit d'expliquer comment :)

Citation:

---

Envoyé par agemis31

Je dirais plutot que parfois faisabilité à tout prix rime avec prise de tête.

---

Oui je suis plutôt d'accord avec toi... mais là en l'occurence pas trop si on veut faire ça vite fait. C'est surtout qu'ici ça rime avec "mauvaise habitude"

Citation:

---

Envoyé par agemis31

j'ai déja eu affaire à quelques "responsables" qui voulaient éviter à tout prix les trous dans les séquences, la plupart du temps pour des raisons purement idéologiques.

---

Effectivement, la plupart du temps ces raisons ne sont pas ou mal fondées. L'idéal est de convaincre le 'dit' responsable qu'avoir une clé IDENTITY c'est mieux. S'il veut absolument avoir un numéro de séquence unique et sans trou de séquence alors ce que je préconiserai c'est une des deux solutions suivantes :
1 - Créer cet identifiant sur une autre colonne (que l'on affichera comme identifiant) et garder une clé unique IDENTITY avec une contrainte d'unicité
2 - La plus compliquée... faire une table ne contenant qu'une colonne de type IDENTITY et la remplir avec 10 000 000 d'enregistrements (par exemple) puis faire la requête suivante qui te renvoie le premier identifiant non utilisé :

Code:

---

SELECT MIN(id) FROM id WHERE NOT EXISTS (SELECT id_user FROM user WHERE id_user = id)

---

Je ne suis pas très fan de cette solution mais au moins elle marche à 100%, mieux que le MAX+1... qui peut laisser des trous si l'insertion est faite dans une transaction avec d'autres requêtes, qu'une requête situé après le MAX+1 plante et qu' au même moment un programme appelle aussi cette transaction...

Donc effectivement le MAX+1 peut ne pas fonctionner à 100%... mais ça laisse un faible probabilité tout ce même, il faut voir le contexte pour prendre la bonne décision. Le MAX+1 restant une solution très légère par rapport à la proposition 2

Bonjour,

On a peut être pas le même vocabulaire,

Quand j'entends identifiant, je pense à quelque chose de stable dont je peux me servir pour les relations, ... mais aussi en dehors de la base (dans des documents bureautiques, des fichiers, ....)

En 1, on parle bien d'identifiant.
En 2, on parle de combler les trous.

D'aileurs depuis le début on parle plutot de combler le trou (récupérer le premier, l'insertion...)

@+