Bonjour, j'espère qlq1 peu m'aider
alors j'veux faire un auto-incrimente d'un ID de type "string" avec asp.net mvc
Version imprimable
Bonjour, j'espère qlq1 peu m'aider
alors j'veux faire un auto-incrimente d'un ID de type "string" avec asp.net mvc
Bonjour,
Selon la base de donnée en amont, à la place d'une chaîne de caractère je pense qu'il serai sans doute plus simple de passer par un uniqueidentifier sous SQL Server dont l'équivalent coté c# sera un Guid dont l'indexation sera forcément plus optimiser côté sql et d'une relative simplicité d'usage côté c#...
Après cela dépend de vos contraintes...
dacc j vais essayer
merci merci
Pour quel type de base de donnée tu as besoin de faire ça, c'est géré nativement avec SQL Server, tu n'as pas besoin de le faire en code.
Salut,
la question que je me pose c'est surtout quelle utilité auras-tu pour ce champ ? Pourquoi vouloir que ce soit une chaine ? Et effectivement, les SGBD ont souvent un truc embarqué pour ça (AUTO_INCREMENT sur int en MySQL/fork, TRIGGER/SEQUENCE ou RowId sous Oracle ...).
j'ai une table PERSONNEL avec sql server j veux que l'ID soit de ce genre "PERS0001"
Pourquoi ?Citation:
Envoyé par hosni.nafaa
Une base de données sait parfaitement gérer des ids et leurs incrémentations (c'est l'intérêt d'un base de données relationnelle).
oui j sais la BD gere parfaitement les IDs de type "int" et incrementation sera auto, mais avec un type "string" il faut ajouter des scripts au code source de l'appli web(c mon prb )
Je sais pas comment fonctionne l'auto incrémentation sur SqlServer mais imaginons qu'on sache faire ça sur un INT. Ce que tu peux alors faire, si tu ne veux vraiment pas faire ça côté code, c'est de poser un TRIGGER AFTER INSERT et mettre à jour ton champs STRING en faisant une concat' avec ton INT auto incrémenté.
Pourquoi vouloir que ton id ressemble à "PERS00001" ?Citation:
Envoyé par hosni.nafaa
Comme les autres SGBD :)Citation:
Envoyé par jopopmk
"PERS0001" c demandé dans le cahier des charges...
Les autres l'ont déja dit , j'insiste , rien ne t'empecher de garder le comportement naitf du SGBD(1,2,3 etc... ) et ensuite avoir ta variable d'affichage coté serveur qui n'est autre que "PERS" + id .
Sinon je crois qu'il ya moyen de configurer le format d'un id directement en base mais j'ai pas été vérifier .
Comme dit plus haut : MySQL et ses forks proposent un attribut AUTO_INCREMENT, alors que pour Oracle il faudra passer par une SEQUENCE/TRIGGER. C'est les deux seuls SGBDR que je pratique (*) et la méthode n'est déjà pas la même. Du coup c'est pas tout à fait pareil pour tous. En plus je m'en voudrais de dire une ânerie sur SqlServer, alors je préfère préciser ;)Citation:
Envoyé par katkiller
(*)J'espère bientôt pouvoir ajouter PostgreSQL à mon arc :oops:
Une cle primaire dans le SGBDR (quel qu'il soit) ne doit jamais avoir une signification quelconque. Donc il ne faut surtout pas avoir comme cle primaire quelque chose comme "PERS0001". C'est une regle absolue en modelisation, et le pourquoi du comment est explique sur ces liens (entre autre) :
- De l'invariance des clés primaires
- Conception d'une base de données - III-B-2. Clés primaires et clés étrangères
- Bases de données relationnelles et normalisation : de la première à la sixième forme normale - 3.2.6. Clé primaire
Et je n'aborderai bien sur pas les consequences d'avoir une cle primaire de type string sur les performances :aie:
Il faut donc avoir une cle primaire neutre, eventuellement auto-incrementee (donc 1, 2, 3, etc.) ou un GUID, et a cote dans une autre colonne, on peut stocker, la cle "fonctionnelle" qui servira aux utilisateurs. Ou alors comme indique plus haut on peut aussi calculer la cle "fonctionnelle" dans le code de l'appli.
Je prefere personnellement stocker la cle fonctionnelle, car si pour une raison ou une autre on doit changer la cle primaire d'un enregistrement, on peut vouloir conserver la meme cle fonctionnelle. Si on la calcule dans le code, ca va etre complique...
Bonjour,
Le mieux et le plus simple dans ton cas c'est :
- D'avoir une colonne de type INT autoincrémenté
- D'avoir une colonne calculée, qui concatène "PERS" avec la colonne ID
Cela évite de devoir calculer l'ID dans le code client, et de devoir stocker cette information dans la BD, tout en conservant des performances optimales vis-à-vis de la clé primaire.
Par contre, une clé primaire GUID (ou même un index en GUID en général) est généralement une TRES mauvaise idée d'un point de vue performance sans quelques précautions...
Effectivement ! Tu fais bien de le preciser sinon gare aux surprises (perfo, stockage, etc.) :aie::plusser:Citation:
Envoyé par François DORIN