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
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Auto incrément Asp.net mvc
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...
Mon blog est sur https://arphonis.fr et bientôt d'autres fonctionnalités seront disponible dessus.
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 ...).
Plus je connais de langages, plus j'aime le C.
j'ai une table PERSONNEL avec sql server j veux que l'ID soit de ce genre "PERS0001"
Pourquoi ?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é.
Plus je connais de langages, plus j'aime le C.
Pourquoi vouloir que ton id ressemble à "PERS00001" ?
Comme les autres SGBD
"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 .
throw new NoSignatureException();
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éciserComme les autres SGBD
(*)J'espère bientôt pouvoir ajouter PostgreSQL à mon arc
Plus je connais de langages, plus j'aime le C.
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
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...
Less Is More
Pensez à utiliser les boutons
,
et les balises code
Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.
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...
François DORIN
Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
Site internet | Profils Viadéo & LinkedIn
---------
Page de cours : fdorin.developpez.com
---------
N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels
Effectivement ! Tu fais bien de le preciser sinon gare aux surprises (perfo, stockage, etc.)
Less Is More
Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager