Quelle est votre convention de dénomination pour les procédures stockées? [fermé]

J'ai vu diverses règles pour nommer les procédures stockées.

Certaines personnes préfixent le nom du 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 devriez pas utiliser sp_ dans SQL Server à moins que vous ne le pensiez vraiment.

Certains commencent le nom du processus 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 contenant 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 aux 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 (Sélectionner, Insérer, Mettre à jour, Supprimer) 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 singluar et pluriel pour indiquer si un ou plusieurs enregistrements sont en cours de récupération.
• 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 ou solutions et projets Management Studio (SQL Server), ou schémas SQL Server.
• Les abréviations insignifiantes doivent être évitées.

Pourquoi j'ai choisi la réponse que j'ai faite: Il y a tellement de bonnes réponses. Merci à tous! Comme vous pouvez le voir, il serait très difficile d'en choisir un seul. Celui que j'ai choisi a résonné avec moi. J'ai suivi le même chemin qu'il décrit - essayer d'utiliser Verb + Noun et ne pas être en mesure de 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. Des problèmes graves peuvent survenir si quelqu'un crée par inadvertance un sproc dupliqué 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 de codage générale pour les noms de méthodes.

Il préconise également le préfixe avec le nom de l'application au lieu du pas très utile usp_. Comme plusieurs personnes l'ont souligné, la base de données contient parfois des sprocs pour plusieurs applications. Ainsi, le préfixe avec le nom de l'application permet de séparer les sprocs ET aide les administrateurs de base de données et autres à déterminer l'application pour laquelle le sproc est utilisé.

Pour mon dernier projet, j'ai utilisé usp_ [Action] [Object] [Process] donc par exemple, usp_AddProduct ou usp_GetProductList, usp_GetProductDetail. Cependant, maintenant que la base de données contient 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 impaires pour l'ajout de produit, et 50 impaires pour l'obtention, etc.

Pour cette raison, dans ma nouvelle application, je prévois de regrouper les noms de procédure par objet, je laisse également tomber l'USP car je pense qu'il est quelque peu redondant, à part 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 permet de regrouper les éléments pour une recherche plus facile 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 référencé dans la section de processus, par exemple App_Product_AddAttribute.

Voici quelques éclaircissements 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 ce préfixe à votre sproc, 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 depuis toutes les bases de données, mais qu'il doit être exécuté dans le contexte de la base de données courante.

Voici une belle explication, qui comprend une démo du hit de performance.

Voici une autre source utile fournie par Ant dans un commentaire.

Les systèmes hongrois (comme le préfixe "usp" ci-dessus) me font frémir.

Nous partageons de nombreuses procédures stockées dans différentes bases de données structurées de manière 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 de la dénomination 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 ", et ainsi de suite.

En réponse au commentaire de Ant:

1. La différence entre une table et une vue concerne ceux qui conçoivent le schéma de base de données, et non ceux qui accèdent ou modifient son contenu. Dans les rares cas où des détails de schéma sont nécessaires, il est assez facile à trouver. Pour la requête SELECT occasionnelle, cela n'est pas pertinent. En fait, je considère le fait de pouvoir traiter les tables et les vues de la même manière comme un gros avantage.
2. 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.
3. Une fonction nécessite que le préfixe de schéma soit appelé. 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 manière, pourquoi pas moi?

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 d'utiliser aujourd'hui:

Préfixe :

• gen - Général: CRUD, principalement
• rpt - Rapport: explicite
• tsk - Tâche: généralement quelque chose avec une logique procédurale, exécuté via des tâches planifiées

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 la table ou de la vue affecté. Pour rpt (Rapport), voici la brève description du rapport. Pour tsk (Tâche), c'est la brève description de la tâche.

Clarificateurs en option:

Il s'agit de 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édures:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

TableName_WhatItDoes

• Comment_GetByID

• Liste de clients

• UserPreference_DeleteByUserID

Pas de préfixes ou de bêtises hongroises idiotes. Juste le nom de la table à laquelle il est le plus étroitement associé et une brève description 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'il trie jusqu'à la fin de la liste où je n'ai pas à le regarder.

Le démarrage d'un nom de procédure stockée avec sp_est incorrect dans SQL Server car les sprocs système commencent tous par sp_. Une 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 divers types d'espaces de noms de la même manière que les préfixes sur les noms. Par exemple, sur un schéma en étoile, on pourrait avoir des schémas dim et fact et se référer aux tables par cette convention.

Pour les procédures stockées, le préfixage est utile pour identifier les sprocs d'application des sprocs système. up_vs sp_rend relativement facile l'identification des procédures stockées non système à partir du dictionnaire de données.

J'encapsule toujours les procédures stockées dans des 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 vous devez être d'accord 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 exemple Réception, Achat, etc. pour les garder groupés (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 '' car le sproc s'appelle uspUsingNoAbbreviationsIncreasesClarityForEveryone)

J'utilise actuellement un format qui ressemble au suivant

Notation:

[PRÉFIXE] [APPLICATION] [MODULE] _ [NOM]

Exemple:

P_CMS_USER_UserInfoGet

J'aime cette notation pour plusieurs raisons:

• commencer par un préfixe très simple permet d'écrire du code pour n'exécuter que 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 exécutent la même architecture de base de données. La notation Application désigne le groupe qui possède le SP.
• Les sections Module et Nom complètent simplement la hiérarchie. Tous les noms doivent pouvoir correspondre au groupe / application, module, fonction de l'hérarchie.

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 par ordre alphabétique par nom de table et par fonctionnalité, il est donc facile de voir ce que je peux faire à 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 l'EDI SQL Server 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 -

• " Obtenir " - 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 _ détails du client

"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 les insertions, les 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.

Je n'ai rencontré aucun inconvénient à cette approche jusqu'à présent.

GetXXX - Obtient XXX en fonction de @ID

GetAllXXX - Obtient tous les XXX

PutXXX - Insère XXX si passé @ID est -1; autre mise à jour

DelXXX - Supprime XXX en fonction de @ID

Je pense que la convention de dénomination usp_ ne sert à rien.

Dans le passé, j'ai utilisé les préfixes Get / Update / Insert / Delete pour les opérations CRUD, mais maintenant que j'utilise Linq to SQL ou EF pour faire la plupart de mon travail CRUD, ils ont entièrement disparu. Comme j'ai si peu de procs stockés dans mes nouvelles applications, les conventions de dénomination n'ont plus d'importance comme avant ;-)

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, le préfixe est donc indispensable.

Si nous n'avions pas la contrainte héritée, je suis tout à fait sûr que nous n'utiliserions pas de préfixe.

Après le préfixe, nous commençons généralement le nom du SP par 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 de mettre l'accent sur la lisibilité, de sorte que ce que la procédure fait à partir du seul nom soit évident.

Les noms de procédure stockée typiques de notre équipe seraient:

shopGetCategories
shopUpdateItem

Je ne pense pas que le préfixe soit vraiment important, 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 gamme d'actions typiques telles que obtenir, définir, archiver, insérer, supprimer, etc. La description du processus est courte mais descriptive, 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 la dénomination des procédures, qui à mon avis cache plus qu'elle ne révèle. Tant que j'énumère 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

É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 processus stockés qui font le travail de POLL vs qui font l'inventaire, etc.

Quoi qu'il en soit, le système de préfixe dépend de votre domaine problématique. Mais tout 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 de l'explorere pour la modifier.

d'autres exemples de fonction.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Nous avons suivi la dénomination basée sur la fonction coz Les Procs s'apparentent à du code / fonction plutôt qu'à des objets statiques comme des 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 cela pourra aider.

J'ai rejoint tardivement le fil mais je veux entrer ma réponse ici:

Dans mes deux derniers projets, il y a différentes tendances comme, dans l'un que nous avons utilisé:

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

Ces conventions de dénomination sont également suivies en frontal en préfixant le mot dt .

Exemple:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

Avec l'aide des conventions de dénomination ci-dessus dans notre application, nous avons de bons noms faciles à retenir.

Alors que dans le deuxième projet, nous avons utilisé les mêmes conventions de dénomination avec une petite différence:

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_MedicationInfoU