Bonjour, Je suis arrivé à cette situation en travaillant dans mon projet, où les gens codent en dur la valeur d'une colonne de clé primaire dans une application. Est-ce une bonne pratique. En traitant des environnements, la valeur de cet enregistrement peut changer, mais que diriez-vous d'utiliser des insertions d'identité dans d'autres environnements.valeur de clé primaire de codage en dur dans les applications
Bien que ce soit évidemment une très mauvaise pratique, j'hésite à rejeter n'importe quoi de pareil sans information décente sur le raisonnement. Je donne habituellement à mes collègues le bénéfice du doute et suppose qu'ils ont réfléchi au problème et arrivent à une conclusion raisonnable, et j'ai simplement besoin d'apprendre à comprendre leur raisonnement.
Il existe certains cas très rares où les identités codées en dur peuvent être une solution OK, par exemple si votre package d'installation crée également la base de données et le schéma et ajoute certaines valeurs de recherche de domaine. Dans de tels cas, la colonne d'identité est définie avec une graine un peu plus élevée que d'habitude (par exemple IDENTITY(100,1)) et les valeurs du système sont toujours placées sous la graine (dans ce cas, 100). Par exemple, vous avez peut-être une table de domaine pour PhoneType et les valeurs 1-3 sont réservées pour "Primary", "Billing" et "Contact". En attendant, les valeurs 100 et plus sont autorisées pour les utilisateurs finaux à définir leurs propres types de téléphone.
Il est définitivement une mauvaise pratique d'insérer des valeurs d'identité codées en dur au cours de l'exécution proprement dite, par ex. en réponse à l'entrée de l'utilisateur. Dans ce cas, il est probablement préférable de trouver une clé naturelle, d'utiliser un GUID ou de développer votre propre système de suivi d'identité.
Je suis en train d'écrire une application qui aura une activité, j'ai une table pour une liste d'activités. J'ai une application console pour les activités, et maintenant j'ai une nouvelle activité qui a une exécution différente. Donc, je veux identifier cette activité dans la même application de la console afin que je puisse avoir une classe et des méthodes différentes pour cela. Recommandez-vous de coder en dur le activityid (Primarykey dans la table des activités) ou le nom de l'activité? –
Si j'utilise un GUID, Voulez-vous dire conserver le même GUID dans des environnements différents? –
Généralement j'ai vu cela où il y a des constantes dans la base de code (comme des enums pour certains types de systèmes de base qui sont fondamentaux pour l'application) qui sont aussi dans la base de données. Il existe de meilleures façons de gérer cela, mais finalement, quelque chose va toujours être codé en dur dans ces cas, même si ce n'est pas la clé primaire. Une clé primaire peut être une clé naturelle, par exemple.
Typiquement, vous verriez seulement cela acceptable pour les entités très fondamentales. Peut-être un type d'organisation ou d'entité dans un programme comme: TYPE_USER, TYPE_GROUP. Vous ne verrez pas cela pour qui sont généralement lookups modifiables par l'utilisateur, ou attendre d'être extensible, ou non fondamental d'une certaine façon, comme VEHICLE_TYPE_CAR, VEHICLE_TYPE_SUV, VEHICLE_TYPE_RV, VEHICLE_TYPE_MOTORCYCLE, etc.
Dans tous les cas, il est un code sentir, et ce n'est pas une pratique qui est une bonne idée à moins que ce soit une énumération fondamentale immuable dans l'architecture.
Non, ce n'est jamais une bonne idée de coder en dur les valeurs d'identité. – Siyual
Si une application est construite de cette manière, recommandez-vous de continuer à le faire? –
Non. Si une application est déjà construite de cette façon, je la changerais dès que je serais capable de le faire. Le codage en dur des valeurs d'identité (* en particulier si vous avez plusieurs environnements *) demande simplement qu'il y ait un problème où les valeurs ne correspondent pas entre les environnements. Pour ne pas mentionner, faire quelque chose comme 'SELECT * FROM SomeTable T JOIN statuts S ON T.StatusId = S.Id WHERE S.Name = 'InProgress' rend votre intention 100% clair, alors que SELECT * FROM SomeTable WHERE StatusId = 3 'crée juste plus de questions, de confusion, et finalement plus de travail pour comprendre son intention. – Siyual