Question

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

Certaines personnes préfixent le nom du sproc avec usp_, d'autres une abréviation du nom de l'application, et d'autres encore 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 de proc avec un verbe (Obtenir, Ajouter, Enregistrer, Supprimer). D'autres mettent l'accent sur le (s) nom (s) de l'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 des noms, il serait peut-être plus important que tout le monde utilise la même convention d'appellation que celle utilisée.
  • Préfixes: Tandis que beaucoup de gens utilisent usp_ ou quelque chose de similaire (mais rarement sp_), beaucoup d’autres utilisent un nom de base de données ou d’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.
  • Le verbe + nom semble être légèrement plus populaire que le nom + verbe. 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 leurs abréviations) comme Get et Add. Certains font la distinction entre les noms singluiers et pluriels 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, solutions et projets Management Studio (SQL Server) ou schémas SQL Server.
  • Les abréviations insoutenables 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 constater, il serait très difficile d’en choisir un seul. Celui que j'ai choisi a résonné avec moi. Il a suivi le même chemin qu’il décrit: essayer d’utiliser Verb + Noun, puis ne pas être en mesure de trouver tous les sprocs qui s’appliquent à Customer.

Pouvoir localiser un sproc existant, ou 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 sous 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 préconiser Verb + Noun, car il suit la convention de codage générale pour les noms de méthodes.

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

Était-ce utile?

La solution

Pour mon dernier projet, j'ai utilisé usp_ [Action] [Objet] [Processus]. Ainsi, par exemple, usp_AddProduct ou usp_GetProductList, usp_GetProductDetail. Cependant, à présent, 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 Add odd pour le produit ajouté, et 50 odd pour la commande Get 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 j'estime qu'il est quelque peu redondant. À part me dire que c'est une procédure, quelque chose que je peux déduire. le 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

Il est utile de regrouper les éléments pour faciliter les recherches ultérieures, en particulier si le nombre de sprocs est important.

En ce qui concerne les endroits où plusieurs objets sont utilisés, je constate que la plupart des instances ont un objet primaire et secondaire. L'objet primaire est donc utilisé dans l'instance normale et l'objet secondaire est référencé dans la section de processus, par exemple, App_Product_AddAttribute.

Autres conseils

Voici quelques éclaircissements sur le problème du préfixe sp_ dans SQL Server.

Les procédures stockées portant le préfixe sp_ sont des sprocs système stockés dans la base de données Master.

Si vous attribuez 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 contextuelle, gaspillant ainsi inutilement des ressources. Et si le sproc créé par l'utilisateur porte 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 bonne explication, qui comprend une démonstration du spectacle frappé.

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

Systèmes hongrois (comme ci-dessus & "; usp &" ; préfixe) me fait frémir.

Nous partageons de nombreuses procédures stockées dans différentes bases de données de structure similaire. Par conséquent, pour les bases de données spécifiques, 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 différents schémas pourrait être une alternative pour se débarrasser de ces préfixes quelque peu laids.

Le nom réel après le préfixe diffère peu de celui de la fonction: il s'agit généralement d'un verbe comme & "Ajouter &", & "Définir &", & "; Générer & ";"! & "; Calculez &"; & "Supprimez &"; 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 est pertinente pour ceux qui conçoivent le schéma de base de données, et non pour ceux qui accèdent à ou modifient son contenu. Dans les rares cas où il est nécessaire de spécifier le schéma, il est assez facile à trouver. Pour la requête SELECT occasionnelle, cela n'a aucune importance. En fait, je considère que pouvoir traiter les tables et les vues de la même manière est 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 qu'il soit autre qu'un ou plusieurs noms.
  3. Une fonction nécessite que le préfixe du 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, le même que 1. s'appliquerait: si je peux traiter les fonctions et les procédures stockées de la même manière, pourquoi ne le devrais-je pas?

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 ils prennent en charge les schémas, qui peuvent être utilisés pour différents types d’espaces de nom de la même manière que les préfixes utilisés pour les noms. Par exemple, sur un schéma en étoile, on peut avoir des schémas dim et fact et faire référence aux tables selon cette convention.

Pour les procédures stockées, le préfixage est utile pour identifier les sprocs d'application à partir des sprocs système. up_ contre <=> facilite l’identification des procédures stockées non système à partir du dictionnaire de données.

TableName_WhatItDoes

  • Comment_GetByID

  • Customer_List

  • UserPreference_DeleteByUserID

Pas de préfixes ou de bêtises hongroises stupides. Juste le nom de la table à laquelle il est le plus étroitement associé et une description rapide de ce qu’elle fait.

Une mise en garde à propos de ce qui précède: personnellement, je préfixe toujours mon CRUD auto-généré avec zCRUD_ afin qu’il soit trié à la fin de la liste où je n’ai pas à le regarder.

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 explicite
  • tsk - Tâche: généralement une tâche à logique de procédure exécutée 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 sert à choisir le spécificateur d'action. Par exemple, un INSERT client peut nécessiter beaucoup de travail de préparation, mais l'objectif général 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 (Report), il s'agit de la brève description du rapport. Pour tsk (tâche), il s'agit de la brève description de la tâche.

Clarificateurs facultatifs:

Ce sont des bits d’informations 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

J'encapsule toujours les procédures stockées dans des packages (j'utilise Oracle au travail). Cela réduira le nombre d'objets distincts et facilitera la réutilisation du code.

La convention de nommage est une question de goût et vous devriez vous mettre 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. Ceci 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 participant au projet n'ont pas à se demander ce que signifie "UNAICFE", car le sproc est nommé uspUsingNoAbbreviationsIncreasesClarityForEveryone)

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:

  • à partir de très simple Le préfixe permet d’écrire du code pour n’exécuter que les 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 utilisent 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'utilise toujours:

usp [Nom de la table] [Action] [Détails supplémentaires]

Étant donné une table appelée & "; tblUser &"; qui 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 pour une table donnée. Utilisation du préfixe & Quot; usp & Quot; faites-moi savoir ce que j'appelle si j'écris (par exemple) une procédure de 1 000 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 performant que Visual Studio, je conserve les préfixes.

application prefix_ operation prefix_ description des objets de la base de données impliqués (moins les espaces entre les traits de soulignement - doit insérer des espaces pour qu'ils apparaissent) .

préfixes d'opération que nous utilisons -

  • & # 8220; obtenir & # 8221; & # 8211; renvoie un jeu d'enregistrements
  • & # 8220; ins & # 8221; & # 8211; insère des données
  • & # 8220; upd & # 8221; & # 8211; met à jour les données
  • & # 8220; del & # 8221; & # 8211; supprime les données

p.ex.

wmt_ ins _ client _détails

& "Outil de gestion des effectifs, insérer des détails dans la table des clients &";

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 (insertions, mises à jour, etc.) sont regroupées.

Ce système fonctionne bien pour nous, avec env. 1000 procédures stockées dans une base de données qui me viennent à l’esprit.

Nous n'avons encore 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 égal à -1; sinon mises à jour

DelXXX - Supprime XXX en fonction de @ID

Je pense que la convention de nommage usp_ ne sert à rien.

Auparavant, j’utilisais les préfixes Get / Update / Insert / Delete pour les opérations CRUD, mais depuis que j’utilise Linq en SQL ou EF pour effectuer la plupart de mes travaux CRUD, ils ont complètement disparu. Depuis que j'ai si peu de procs stockés dans mes nouvelles applications, les conventions de nommage n'ont plus d'importance comme avant; -)

Pour l’application en cours 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 existante 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 décrivant le fonctionnement de la procédure, puis par 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 qu'il soit évident que la procédure fonctionne uniquement à partir du nom.

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

shopGetCategories
shopUpdateItem

Je ne pense pas que le préfixe soit important dans la mesure où 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 quelque chose de court mais descriptif, par exemple

spu_archiveCollectionData 

ou

spu_setAwardStatus

Je nomme mes fonctions de la même manière, mais avec le préfixe 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 n'en révèle. Tant que, lorsque je répertorie mes procédures par ordre alphabétique, je peux les voir regroupées par fonctionnalité, ce qui me semble être le compromis idéal entre ordre et rigueur inutile

Evitez sp_ * dans le serveur SQL car tous les paramètres stockés dans le système commencent par sp_; il est donc de plus en plus difficile pour le système de trouver l’objet correspondant au nom.

Donc, si vous commencez avec 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 un grand fichier de schéma est présenté.

En dehors de cela, nous attribuons un préfixe identifiant la fonction. Comme

Proc_Poll_Interface, Proc_Inv_Interface etc.

Cela nous permet de trouver tous les processus stockés qui remplissent les fonctions de POLL par rapport à Inventory, etc.

De toute façon, le système de préfixe dépend de votre domaine problématique. Mais al a dit et fait quelque chose de similaire devrait être présent même si c’est juste pour permettre aux gens de localiser rapidement la procédure stockée dans le menu déroulant explorere pour le montage.

autres exemples de fonction.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Nous avons suivi le nommage basé sur la fonction car les procs ressemblent à du code / fonction plutôt qu’à des objets statiques tels que des tableaux. Cela n'aide pas que Procs puisse travailler avec plus d'une table.

Si le proc exécute 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 scinder à nouveau.

L’espoir que cela aide.

J'ai rejoint le fil en retard mais je souhaite entrer ma réponse ici:

Dans mes deux derniers projets, il existe différentes tendances, comme celle que nous avons utilisée:

  

Pour obtenir des données: s < nomdetable > _G
  Pour supprimer des données: s & Lt; tablename & Gt; _D
  Pour insérer des données: s & Lt; tablename & Gt; _I
  Pour mettre à jour les données: s & Lt; tablename & Gt; _U

Cette convention de dénomination est également suivie en amont du préfixe dt .

Exemple:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

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

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

  

Pour obtenir des données: sp _ < nomdetable > G
  Pour supprimer des données: sp _ & Lt; tablename & Gt; D
  Pour insérer des données: sp _ & Lt; tablename & Gt; I
  Pour mettre à jour les données: sp _ & Lt; tablename & Gt; U

Exemple:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top