Quelle est votre convention de dénomination pour les procédures stockées?
J'ai vu diverses règles pour nommer les procédures stockées.
Certaines personnes préfixent le nom sproc avec usp_, d'autres avec une abréviation pour le nom de l'application et d'autres encore avec un nom de propriétaire. Vous ne devez pas utiliser sp_ dans SQL Server sauf si vous le pensez vraiment.
Certains commencent le nom du proc par un verbe (Get, Add, Save, Remove). D'autres mettent l'accent sur le (s) nom (s) d'entité.
Sur une base de données avec des centaines de sprocs, il peut être très difficile de faire défiler et de trouver un sproc approprié lorsque vous pensez qu'il en existe déjà un. Les conventions de dénomination peuvent faciliter la localisation d'un sproc.
Utilisez-vous une convention de dénomination? Veuillez le décrire et expliquer pourquoi vous le préférez à d'autres choix.
Résumé des réponses:
- Tout le monde semble prôner la cohérence de la dénomination, qu'il pourrait être plus important pour tout le monde d'utiliser la même convention de dénomination que celle qui est utilisée.
- Préfixes: Alors que beaucoup de gens utilisent usp_ ou quelque chose de similaire (mais rarement sp_), beaucoup d'autres utilisent le nom de la base de données ou de l'application. Un DBA intelligent utilise gen, rpt et tsk pour distinguer les sprocs CRUD généraux de ceux utilisés pour les rapports ou les tâches.
- Verb + Noun semble être légèrement plus populaire que Noun + Verb. Certaines personnes utilisent les mots clés SQL (Select, Insert, Update, Delete) pour les verbes, tandis que d'autres utilisent des verbes non SQL (ou des abréviations pour eux) comme Get et Add. Certains font la distinction entre les noms singuliers et les noms pluriels pour indiquer si un ou plusieurs enregistrements sont récupérés.
- Une phrase supplémentaire est suggérée à la fin, le cas échéant. GetCustomerById, GetCustomerBySaleDate.
- Certaines personnes utilisent des traits de soulignement entre les segments de nom et d'autres évitent les traits de soulignement. app_ Get_Customer vs appGetCustomer - Je suppose que c'est une question de lisibilité.
- De grandes collections de sprocs peuvent être séparées en packages Oracle, en solutions et projets Management Studio (SQL Server) ou en schémas SQL Server.
- Les abréviations non crédibles doivent être évitées.
Pourquoi j'ai choisi la réponse que j'ai faite: Il y a SO beaucoup de bonnes réponses. Merci à tous! Comme vous pouvez le voir, il serait très difficile d'en choisir une seule. Celui que j'ai choisi a résonné avec moi. J'ai suivi le même chemin qu'il décrit - en essayant d'utiliser Verbe + Nom et ensuite de ne pas pouvoir trouver tous les sprocs qui s'appliquent au Client.
Être capable de localiser un sproc existant, ou de déterminer s'il en existe un, est très important. De graves problèmes peuvent survenir si quelqu'un crée par inadvertance un sproc en double avec un autre nom.
Comme je travaille généralement sur de très grandes applications avec des centaines de sprocs, j'ai une préférence pour la méthode de dénomination la plus facile à trouver. Pour une application plus petite, je pourrais recommander Verb + Noun, car il suit la convention générale de codage pour les noms de méthode.
Il préconise également le préfixe avec le nom de l'application au lieu de usp_ pas très utile. Comme plusieurs personnes l'ont souligné, la base de données contient parfois des sprocs pour plusieurs applications. Ainsi, le préfixe du nom de l'application permet de séparer les sprocs ET aide les administrateurs de base de données et autres à déterminer pour quelle application le sproc est utilisé.
Pour mon dernier projet, j'ai utilisé usp_ [Action] [Object] [Process], par exemple, usp_AddProduct ou usp_GetProductList, usp_GetProductDetail. Cependant, maintenant que la base de données compte plus de 700 procédures, il devient beaucoup plus difficile de trouver toutes les procédures sur un objet spécifique. Par exemple, je dois maintenant rechercher 50 procédures d'ajout impair pour l'ajout de produit, et 50 impaires pour le Get, etc.
Pour cette raison, dans ma nouvelle application, je prévois de regrouper les noms de procédure par objet, je supprime également l'USP car je pense qu'il est quelque peu redondant, sauf pour me dire que c'est une procédure, quelque chose que je peux déduire du nom de la procédure elle-même.
Le nouveau format est le suivant
[App]_[Object]_[Action][Process]
App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add
App_Product_GetList
App_Product_GetSingle
Cela aide à regrouper les choses pour les retrouver plus facilement plus tard, surtout s'il y a une grande quantité de sprocs.
En ce qui concerne l'utilisation de plusieurs objets, je trouve que la plupart des instances ont un objet principal et secondaire, donc l'objet principal est utilisé dans l'instance normale et le secondaire est mentionné dans la section processus, par exemple App_Product_AddAttribute.
Voici quelques précisions sur le problème du préfixe sp_ dans SQL Server.
Les procédures stockées nommées avec le préfixe sp_ sont des sprocs système stockés dans la base de données Master.
Si vous donnez à votre sproc ce préfixe, SQL Server les recherche d'abord dans la base de données Master, puis dans la base de données de contexte, gaspillant ainsi inutilement des ressources. Et, si le sproc créé par l'utilisateur a le même nom qu'un sproc système, le sproc créé par l'utilisateur ne sera pas exécuté.
Le préfixe sp_ indique que le sproc est accessible à partir de toutes les bases de données, mais qu'il doit être exécuté dans le contexte de la base de données actuelle.
Voici une belle explication, qui comprend une démo de la performance.
Voici une autre source utile fournie par Ant dans un commentaire.
Systèmes hongrois (comme le préfixe "usp" ci-dessus) me fait frémir.
Nous partageons de nombreuses procédures stockées dans différentes bases de données de structure similaire, donc pour celles spécifiques à la base de données, nous utilisons un préfixe du nom de la base de données lui-même; les procédures partagées n'ont pas de préfixe. Je suppose que l'utilisation de schémas différents pourrait être une alternative pour se débarrasser complètement de ces préfixes quelque peu laids.
Le nom réel après le préfixe n'est guère différent du nom de fonction: généralement un verbe comme "Ajouter", "Définir", "Générer", "Calculer", "Supprimer", etc., suivi de plusieurs noms plus spécifiques tels que "Utilisateur" "," DailyRevenues ", etc.
En réponse au commentaire de Ant:
- La différence entre une table et une vue est pertinente pour ceux qui conçoivent le schéma de base de données, pas pour ceux qui accèdent ou modifient son contenu. Dans les rares cas où vous avez besoin de spécificités de schéma, c'est assez facile à trouver. Pour la requête SELECT occasionnelle, elle n'est pas pertinente. En fait, je considère pouvoir traiter les tables et les vues de la même manière qu'un gros avantage.
- Contrairement aux fonctions et aux procédures stockées, il est peu probable que le nom d'une table ou d'une vue commence par un verbe ou soit autre chose qu'un ou plusieurs noms.
- Une fonction nécessite d'appeler le préfixe de schéma. En fait, la syntaxe d'appel (que nous utilisons de toute façon) est très différente entre une fonction et une procédure stockée. Mais même si ce n'était pas le cas, la même chose que 1. s'appliquerait: si je peux traiter les fonctions et les procédures stockées de la même façon, pourquoi ne le ferais-je pas?
Démarrage d'un nom de procédure stockée avecsp_ est mauvais dans SQL Server car les sprocs système commencent tous par sp_. La dénomination cohérente (même dans la mesure de hobgoblin-dom) est utile car elle facilite les tâches automatisées basées sur le dictionnaire de données. Les préfixes sont légèrement moins utiles dans SQL Server 2005 car il prend en charge les schémas, qui peuvent être utilisés pour différents types d'espaces de noms de la même manière que les préfixes des noms. Par exemple, sur un schéma en étoile, on pourrait avoir des schémas dim et fact et se référer aux tableaux selon cette convention.
Pour les procédures stockées, le préfixe est utile pour identifier les sprocs d'application des sprocs système. up_ contre. sp_ facilite l'identification des procédures stockées non système à partir du dictionnaire de données.
J'ai utilisé à peu près tous les différents systèmes au fil des ans. J'ai finalement développé celui-ci, que je continue à utiliser aujourd'hui:
Préfixe :
- gen - Général: CRUD, principalement
- rpt - Rapport: auto-explicatif
- tsk - Tâche: généralement quelque chose avec une logique procédurale, exécuté via des travaux planifiés
Spécificateur d'action:
Ins - INSERT
Sel - SELECT
Upd - UPDATE
Del - DELETE
(Dans les cas où la procédure fait beaucoup de choses, l'objectif global est utilisé pour choisir le spécificateur d'action. Par exemple, un client INSERT peut nécessiter beaucoup de travail de préparation, mais l'objectif global est INSERT, donc "Ins" est choisi.
Objet:
Pour gen (CRUD), il s'agit du nom de table ou de vue affecté. Pour rpt (Report), voici la courte description du rapport. Pour tsk (tâche), voici la courte description de la tâche.
Clarificateurs facultatifs:
Ce sont des bits d'information facultatifs utilisés pour améliorer la compréhension de la procédure. Les exemples incluent "Par", "Pour", etc.
Format:
[Préfixe] [Spécificateur d'action] [Entité] [Clarificateurs facultatifs]
Exemples de noms de procédure:
genInsOrderHeader
genSelCustomerByCustomerID
genSelCustomersBySaleDate
genUpdCommentText
genDelOrderDetailLine
rptSelCustomersByState
rptSelPaymentsByYear
tskQueueAccountsForCollection
TableName_WhatItDoes
Comment_GetByID
Liste de clients
UserPreference_DeleteByUserID
Pas de préfixes ni de bêtises hongroises idiotes. Juste le nom du tableau auquel il est le plus étroitement associé et une description rapide de ce qu'il fait.
Une mise en garde à ce qui précède: personnellement, je préfixe toujours tous mes CRUD générés automatiquement avec zCRUD_ afin qu'ils soient triés à la fin de la liste où je n'ai pas à les regarder.
J'utilise actuellement un format semblable au suivant
Notation:
[PRÉFIXE] [APPLICATION] [MODULE] _ [NOM]
Exemple:
P_CMS_USER_UserInfoGet
J'aime cette notation pour plusieurs raisons:
- commencer avec un préfixe très simple permet d'écrire du code pour exécuter uniquement des objets commençant par le préfixe (pour réduire l'injection SQL, par exemple)
- dans notre environnement plus large, plusieurs équipes travaillent sur différentes applications qui fonctionnent avec la même architecture de base de données. La notation Application désigne le groupe propriétaire du SP.
- Les sections Module et Nom complètent simplement la hiérarchie. Tous les noms doivent pouvoir être mis en correspondance avec Groupe/Application, Module, Fonction de la hiérarchie.
J'encapsule toujours les procédures stockées dans packages (j'utilise Oracle, au travail). Cela réduira le nombre d'objets séparés et facilitera la réutilisation du code.
La convention de dénomination est une question de goût et quelque chose que vous devez accepter avec tous les autres développeurs au début du projet.
pour les petites bases de données, j'utilise uspTableNameOperationName, par exemple uspCustomerCreate, uspCustomerDelete, etc. Cela facilite le regroupement par entité "principale".
pour les bases de données plus volumineuses, ajoutez un nom de schéma ou de sous-système, par ex. Réception, achat, etc. pour les regrouper (car le serveur SQL aime les afficher par ordre alphabétique)
j'essaie d'éviter les abréviations dans les noms, pour plus de clarté (et les nouvelles personnes sur le projet n'ont pas à se demander ce que signifie 'UNAICFE' parce que le sproc est nommé uspUsingNoAbbreviationsIncreasesClarityForEveryone)
J'utilise toujours:
usp [Nom de la table] [Action] [Détails supplémentaires]
Étant donné une table appelée "tblUser", cela me donne:
- uspUserCreate
- uspUserSelect
- uspUserSelectByNetworkID
Les procédures sont triées alphabétiquement par nom de table et par fonctionnalité, il est donc facile de voir ce que je peux faire pour une table donnée. L'utilisation du préfixe "usp" me permet de savoir ce que j'appelle si j'écris (par exemple) une procédure de 1000 lignes qui interagit avec d'autres procédures, plusieurs tables, fonctions, vues et serveurs.
Jusqu'à ce que l'éditeur de SQL Server IDE soit aussi bon que Visual Studio, je garde les préfixes.
application prefix_ operation prefix_ description des objets de base de données impliqués (moins les espaces entre les traits de soulignement - a dû mettre des espaces pour qu'ils apparaissent) .
préfixes d'opération que nous utilisons -
- " get " - renvoie un jeu d'enregistrements
- " ins " - insère des données
- " upd " - met à jour les données
- “ del ” - supprime les données
par exemple
wmt_ ins _ client _détails
"outil de gestion des effectifs, insérer les détails dans le tableau client"
avantages
Toutes les procédures stockées relatives à la même application sont regroupées par nom. Au sein du groupe, les procédures stockées qui effectuent le même type d'opération (par exemple, insertions, mises à jour, etc.) sont regroupées.
Ce système fonctionne bien pour nous, ayant env. 1000 procédures stockées dans une base de données du haut de ma tête.
Jusqu'à présent, nous n'avons rencontré aucun inconvénient à cette approche.
GetXXX - Obtient XXX basé sur @ID
GetAllXXX - Obtient tous les XXX
PutXXX - Insère XXX si passé @ID est -1; sinon mises à jour
DelXXX - Supprime XXX en fonction de @ID
Évitez sp_ * dans le serveur SQl car toutes les procédures stockées par le système commencent par sp_ et il devient donc plus difficile pour le système de trouver l'objet correspondant au nom.
Donc, si vous commencez par autre chose que sp_, les choses deviennent plus faciles.
Nous utilisons donc une dénomination commune de Proc_ pour commencer. Cela facilite l'identification des procédures si elles sont présentées avec un seul gros fichier de schéma.
En dehors de cela, nous attribuons un préfixe qui identifie la fonction. Comme
Proc_Poll_Interface, Proc_Inv_Interface etc.
Cela nous permet de trouver tous les proc stockés qui font le travail de POLL vs qui font l'inventaire, etc.
Quoi qu'il en soit, le système de préfixes dépend de votre domaine problématique. Mais al dit et fait quelque chose de similaire devrait être présent même si ce n'est que pour permettre aux gens de localiser rapidement la procédure stockée dans la liste déroulante explorere pour l'édition.
autres par exemple de fonction.
Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History
Nous avons suivi le processus de nommage basé sur les fonctions. Les procs s'apparentent au code/fonction plutôt qu'aux objets statiques comme les tables. Cela n'aide pas que Procs puisse fonctionner avec plus d'une table.
Si le proc a exécuté plus de fonctions que ce qui peut être géré dans un seul nom, cela signifie que votre proc fait beaucoup plus que nécessaire et qu'il est temps de les diviser à nouveau.
J'espère que ça t'as aidé.
J'ai rejoint tard le fil mais je veux entrer ma réponse ici:
Dans mes deux derniers projets, il y a différentes tendances, comme celle que nous avons utilisée:
Pour obtenir des données: s <tablename> _G
Pour supprimer des données: s <tablename> _D
Pour insérer des données: s <tablename> _I
Pour mettre à jour les données: s <tablename> _U
Cette convention de dénomination est également suivie en front-end en préfixant le mot dt.
Exemple:
exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_UAvec l'aide des conventions de dénomination ci-dessus dans notre application, nous avons un bon nom facile à retenir.
Alors que dans le deuxième projet, nous avons utilisé les mêmes conventions de dénomination avec une différence de lill:
Pour obtenir des données: sp_ <tablename> G
Pour supprimer des données: sp_ <tablename> D
Pour insérer des données: sp_ <tablename> I
Pour mettre à jour les données: sp_ <tablename> U
Exemple:
exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoUJe pense que la convention de nommage usp_ ne sert à personne.
Dans le passé, j'ai utilisé les préfixes Get/Update/Insert/Delete pour les opérations CRUD, mais maintenant depuis que j'utilise Linq to SQL ou l'EF pour faire la plupart de mon travail CRUD, ceux-ci ont complètement disparu. Étant donné que j'ai si peu de proc stockés dans mes nouvelles applications, les conventions de dénomination n'ont plus d'importance comme auparavant ;-)
Pour l'application actuelle sur laquelle je travaille, nous avons un préfixe qui identifie le nom de l'application (quatre lettres minuscules). La raison en est que notre application doit pouvoir coexister avec une application héritée dans la même base de données, donc le préfixe est un must.
Si nous n'avions pas la contrainte héritée, je suis sûr que nous n'utiliserions pas de préfixe.
Après le préfixe, nous commençons généralement le nom SP avec un verbe qui décrit ce que fait la procédure, puis le nom de l'entité sur laquelle nous opérons. La pluralisation du nom de l'entité est autorisée - Nous essayons pour souligner la lisibilité, de façon à ce que la procédure ne soit évidente qu'à partir du nom.
Les noms de procédures stockées typiques de notre équipe seraient:
shopGetCategories
shopUpdateItem
Je ne pense pas que ce soit vraiment important quel est votre préfixe tant que vous êtes logique et cohérent. Personnellement j'utilise
spu_ [description de l'action] [description du processus]
où la description de l'action fait partie d'une petite série d'actions typiques telles que get, set, archive, insert, delete etc. La description du processus est quelque chose de court mais descriptif, par exemple
spu_archiveCollectionData
ou
spu_setAwardStatus
Je nomme mes fonctions de la même manière, mais préfixe avec udf_
J'ai vu des gens essayer d'utiliser la notation pseudo-hongroise pour nommer les procédures, ce qui, à mon avis, cache plus qu'il ne révèle. Tant que lorsque je répertorie mes procédures par ordre alphabétique, je peux les voir regroupées par fonctionnalité, alors pour moi cela semble être le juste milieu entre l'ordre et la rigueur inutile