Qu'est-ce que votre convention de nommage pour les procédures stockées?

Question

J'ai vu des diverses règles de nommage des procédures stockées.

Certaines personnes préfixe le nom de la procédure stockée 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 Serveur, à moins que vous vraiment l'entendez.

Certains commencent à le proc nom par un verbe (d'Obtenir, d'Ajouter, Enregistrer, Supprimer). D'autres soulignent le nom de l'entité(s).

Sur une base de données avec des centaines de sprocs, il peut être très difficile à parcourir et trouver une procédure stockée lorsque vous pensez que l'un existe déjà. Les conventions de nommage peut, la localisation d'une procédure stockée plus facile.

Pensez-vous utiliser une convention de nommage? Veuillez décrire et expliquer pourquoi vous le préférez plus d'autres choix.

Résumé des réponses:

• Tout le monde semble défendre la cohérence de la désignation, qu'il pourrait être plus important pour tout le monde à utiliser la même convention de nommage que le particulier qui est utilisé.
• Préfixes: Alors que beaucoup de gens utilisent usp_ ou quelque chose de similaire (mais rarement sp_), beaucoup d'autres l'utilisation de la base de données ou le nom de l'application. Un astucieux DBA utilise gen, rpt et tsk de distinguer général CRUD sprocs de celles utilisées pour les rapports ou les tâches.
• Verbe + Nom semble être légèrement plus populaire que le Nom + Verbe. Certaines personnes utilisent les mots-clés SQL (Select, Insert, Update, Delete) pour les verbes, tandis que d'autres utilisent des non-SQL verbes (ou des abréviations pour eux) comme vous et Ajouter. Certains distinguer entre singluar et le pluriel des noms pour indiquer si un ou plusieurs dossiers sont en cours de récupération.
• Un nouveau membre de phrase est proposée à la fin, le cas échéant. GetCustomerById, GetCustomerBySaleDate.
• Certaines personnes utilisent des caractères de soulignement entre le nom de segments, et d'éviter certains des 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és en packages Oracle ou Management Studio (SQL Server) des solutions et des projets, ou SQL Server schémas.
• Insondable abréviations doivent être évités.

Pourquoi j'ai choisi la réponse que j'ai fait: Il y a TELLEMENT de bonnes réponses. Merci à vous tous! Comme vous pouvez le voir, il serait très difficile d'en choisir un. 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 + Substantif et puis ne pas être en mesure de trouver toutes les sprocs qui s'appliquent à la Clientèle.

Être capable de localiser un existant, la procédure stockée, ou pour déterminer si l'un existe, est très important. De graves problèmes peuvent survenir si quelqu'un par inadvertance crée une copie de la procédure stockée avec un autre nom.

Depuis que je travaille généralement sur de très grandes applications avec des centaines de sprocs, j'ai une préférence pour le plus facile à trouver de la méthode de nommage. Pour une petite application, j'ai peut défendre le Verbe + Nom, comme il suit, dans les grandes convention de codage pour les noms de méthode.

Il préconise également de préfixer avec le nom de l'application au lieu de la pas très utile usp_. Comme plusieurs personnes nous ont fait remarquer que, parfois, la base de données contient sprocs pour de multiples applications. Ainsi, les préfixant avec le nom de l'application permet de séparer les sprocs ET aide les Administrateurs de bases de données et les autres afin de déterminer l'application de la procédure stockée est utilisée pour.

Answer 1

Pour mon dernier projet, j'ai utilisé usp_[Action][Objet][Processus] ainsi, par exemple, usp_AddProduct ou usp_GetProductList, usp_GetProductDetail. Mais maintenant, la base de données est à 700 procédures de plus, il devient beaucoup plus difficile de trouver toutes les procédures sur un objet spécifique. Par exemple, j'ai maintenant à la recherche de 50 bizarre Ajouter des procédures pour le Produit ajouter, et 50 étrange pour l'Obtenir, etc.

De ce fait, dans ma nouvelle application que je suis de la planification sur le regroupement des noms de procédure par l'objet, je suis aussi à la baisse de l'usp car j'ai l'impression qu'il est un peu redondante, autres que pour me raconter ses une procédure, quelque chose que je peux déduire le nom de la procédure elle-même.

Le nouveau format est comme suit

[App]_[Object]_[Action][Process]

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

Il permet à un groupe de choses plus facile pour trouver plus tard, surtout si il y a une grande quantité de sprocs.

Concernant les cas où plus d'un objet est utilisé, je trouve que la plupart des cas, primaire et secondaire de l'objet, de sorte que le principal objet est utilisé dans l'instance normale, et la secondaire est référencé dans la section processus, par exemple App_Product_AddAttribute.

Answer 2

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

Procédures stockées nommé par le préfixe sp_ sont système sprocs stockées dans la base de données Master.

Si vous donnez votre procédure stockée ce préfixe, SQL Server cherche dans la base de données Master en premier, puis le contexte de base de données, ainsi inutilement le gaspillage des ressources. Et, si l'utilisateur a créé la procédure stockée a le même nom qu'un système de procédure stockée, l'utilisateur créé la procédure stockée ne sera pas exécutée.

Le sp_ préfixe indique que la procédure stockée est accessible à partir de toutes les bases de données, mais qu'elle doit être exécutée dans le contexte de la base de données actuelle.

Voici une belle explication, qui comprend une démonstration de l'impact sur les performances.

Voici une autre source utile fournie par la Fourmi dans un commentaire.

Answer 3

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

Nous partageons de nombreuses procédures stockées à travers les différentes, de la même façon structurée bases de données, afin de base de données spécifiques, nous utilisons un préfixe de la base de données nom lui-même, le partage des procédures n'ont pas de préfixe. Je suppose qu'à l'aide de différents schémas pourraient être une alternative pour se débarrasser de ces un peu laid préfixes tout à fait.

Le nom réel après le préfixe n'est guère différente de la fonction de nommage: en général, un verbe comme "Ajouter", "Set", "Générer", "Calculer", "Supprimer", etc., suivi par plusieurs plus spécifique des noms propres comme "Utilisateur", "DailyRevenues", et ainsi de suite.

Répondre à la Fourmi commentaire:

1. La différence entre une table et une vue est pertinent à ceux qui conçoivent le schéma de base de données, pas de ceux qui ont accès ou modifier son contenu. Dans les rares cas de besoin de schéma de détails, il est assez facile à trouver. Pour le casual requête SELECT, il n'est pas pertinent. En fait, j'estime être en mesure de traiter des tables et des vues de la même comme un grand avantage.
2. Contrairement aux fonctions et procédures stockées, le nom d'une table ou la vue est peu probable que de commencer par un verbe, ou d'être tout sauf un ou plusieurs noms.
3. Une fonction nécessite le schéma préfixe d'être 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 même que le 1er. : si je peux traiter les fonctions et procédures stockées de la même, pourquoi ne devrais-je pas?

Answer 4

Départ nom d'une procédure stockée avecsp_ est mauvais dans SQL Server, car le système sprocs commencent tous par sp_. Nom cohérentes (à la limite même de lutin-dom) est utile, car il facilititates tâches automatisées sur la base des données de dictionnaire. Les préfixes sont un peu moins utile dans SQL Server 2005, il prend en charge les schémas, qui peut être utilisé pour différents types d'espaces de noms dans la façon dont les préfixes sur des noms utilisés. Par exemple, sur un schéma en étoile, que l'on pouvait avoir dim et fait des schémas et reportez-vous aux tableaux de la présente convention.

Pour les procédures stockées, la préfixation est utile aux fins de l'identification de l'application sprocs de système sprocs. up_ vs sp_ , il est relativement facile d'identifier les non-système de procédures stockées à partir du dictionnaire de données.

Answer 5

J'ai utilisé quasiment tous les systèmes différents au fil des ans. J'ai finalement développé celui-ci, qui je continuer à l'utiliser aujourd'hui:

Préfixe :

• gen - Général: CRUD, surtout
• rpt - Rapport: auto-explicatif
• tsk - Tâche: d'habitude, quelque chose avec une logique procédurale, via des tâches planifiées

Action Rédacteur De Devis:

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 l'action spécificateur. Par exemple, un client peut INSÉRER nécessite un bon travail de préparation, mais l'objectif global est d'INSÉRER, de sorte que "Ins" qui est choisi.

Objet:

Pour gen (CRUD), c'est le nom de table ou vue d'être affecté. Pour la rpt (Rapport), c'est la description courte du rapport. Pour tsk (Tâche) c'est la description courte de la tâche.

En Option Clarificateurs:

Ces options sont facultatives bits d'information utilisées pour améliorer la compréhension de la procédure. Exemples: "Par", "Pour", etc.

Format:

[Préfixe][Action Spécificateur][L'Entité][Facultatif Clarificateurs]

Exemples de noms de procédure:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection