Y a-t-il une raison d'utiliser des noms de table extrêmement abrégés?

Nous utilisons une configuration de base de données à partir d'une application d'un fournisseur qui a horriblement difficile à lire les noms de table de base de données, et aucune documentation sur ce qui est stocké où. Je peux voir pourquoi on peut vouloir obscurcir leur structure de table dans une application propriétaire, mais l'un des arguments de vente de cette application (Enterprise Resource Planning) était sa personnalisation.

Les noms de table sont comme aptrx (Comptes fournisseurs) et apmaster_all (curieusement, c'est la table des fournisseurs). C'est une base de données extrêmement complexe, donc je me demandais s'il y avait une logique à la convention ou si elle était simplement obscurcie intentionnellement ou autrement.

À ma connaissance, la longueur du nom de la table n'affectera pas sensiblement les performances, n'est-ce pas? La base de données est très complexe (des centaines de tables), donc le tri est logique, mais je ne peux pas imaginer pourquoi AccountsPayableTransactions n'est pas préférable à aptrx ....

Oracle a une longue limite de noms de table de 30 caractères. Je soupçonne qu'il s'agit d'un problème hérité basé sur un environnement 16 bits d'origine.
La longueur d'un nom de table pourrait avoir un effet minuscule sur les performances car tous les noms doivent être stockés dans un dictionnaire de données et également analysés pour les requêtes, mais je ne pense pas que vous puissiez mesurer le hit.

Un effet plus important des noms de table courts est qu'il est difficile de travailler avec. Moi aussi, je dois maintenir un schéma de base de données d'entreprise avec des noms courts. Il n'y a aucune bonne raison d'avoir des noms de table courts. La facilité d'entretien l'emporte à chaque fois sur l'obscurcissement ou les anciennes habitudes DOS.

Je pense qu'il y a encore deux choses à dire ou à développer:

1. Nommer les choses n'est pas aussi trivial qu'il y paraît

   Il n'y a que deux problèmes difficiles en informatique: l'invalidation du cache et le nommage. Phil Karlton

2. Alors que les noms courts sans signification sont toujours mauvais, les noms longs ne sont pas toujours bons - notre cerveau a un seuil tl; dr intégré qui est étonnamment bas. 30 caractères suffisent généralement , mais je préfère le SGBDR pour autoriser davantage les cas exceptionnels lorsqu'il ne l'est pas (et tout comme dans la langue, les noms plus longs sont plus utiles pour les choses dont nous ne parlons pas si souvent - comme les noms de contraintes, et les noms plus courts sont plus utiles pour les tableaux que nous interrogeons tout le temps)

Je suis toujours tenté de passer trop peu de temps à choisir des noms, et je le regrette toujours plus tard si je le fais - changer de nom ne se produit que rarement

Paresse. Les options IntelliSense et tierces font de la saisie une véritable excuse difficile à justifier. Je préfère de beaucoup que les noms contiennent des mots significatifs et lisibles.

Les noms de table sont comme aptrx (Comptes fournisseurs) et apmaster_all (curieusement, c'est la table des fournisseurs). C'est une base de données extrêmement complexe, donc je me demandais s'il y avait une logique à la convention ou si elle était simplement obscurcie intentionnellement ou autrement.

Les abréviations bien connues sont généralement préférables à l'énoncé des choses. Lorsqu'une abréviation est bien connue de certaines personnes, mais pas assez, nous cessons de l'appeler une abréviation et commençons à l'appeler un code.

Les abréviations économisent de l'espace sur des plates-formes qui ont des limites strictes, bien que ce soit moins important maintenant qu'il y a 30 ans. (Je me souviens avoir travaillé sur un système dans les années 1980 qui vous limitait à 6 ou 8 caractères pour un nom de table.)

Les abréviations facilitent généralement la lecture des noms de table et des colonnes, tant que l'abréviation est bien effectuée. Si j'ai travaillé sur du code pour AP toute la journée, je préfère lire les noms de colonnes comme "ap_trx.inv_num" plutôt que "accounts_payable_transactions.invoice_number". (J'aime les traits de soulignement.) La saisie de noms longs n'est pas vraiment un problème avec un bon éditeur de texte.

Dans les systèmes comptables, "ap" et "trx" sont des abréviations bien connues. Les autres comprennent "ar", "gl" et "gj", pour les comptes débiteurs, le grand livre général et le journal général.

Dans un système bien conçu, si je trouvais des transactions de comptes créditeurs dans un tableau nommé "aptrx", j'espère trouver des transactions de comptes clients dans artrx, des transactions du grand livre général dans gltrx, etc. Je trouve "apmaster_all" un peu déroutant, mais si je trouvais également "armaster_all", je présumerais que le premier détenait tous les fournisseurs (par opposition aux fournisseurs actifs ou inactifs), et que le second détenait également tous les clients.

Dans d'autres domaines problématiques, vous trouverez d'autres abréviations bien connues. Dans l'adressage, vous trouverez des abréviations comme "addr" pour l'adresse, "st" pour la rue, "usps" pour le United States Postal Service, "ups" pour United Parcel Service, "cty" pour le comté, "zip" pour l'amélioration de la zone Code, etc.

Je n'appellerais pas cela de l'obscurcissement. Si les transactions des comptes créditeurs étaient stockées dans une table nommée "cdrs21", j'appellerais cela de l' obscurcissement. (Bien que j'aie travaillé une fois pour une entreprise qui a nommé tous ses modules d'assemblage mainframe de cette façon. Limites de caractères, pas d'obscurcissement.)

Mais les bases de données utiles se développent et vous rencontrez un problème lorsque les bases de données deviennent volumineuses. Lorsque vous ajoutez des domaines problématiques à votre base de données, vous rencontrez des situations où des abréviations connues entrent en collision. Si vous traitez avec les médias, «ap» peut également abréger «Associated Press», «alternative press» ou «advance placement». Lorsque cela se produit, il est temps d'abandonner les abréviations ou de passer aux codes. Plus l'organisation est grande (et plus la base de données est grande), plus je trouve des codes fréquemment.

Juste sonner avec "mon dieu, les lunettes, ils ne font rien pour cette horrible convention de dénomination". L'équipe de gestion des données de mon dernier environnement a indiqué que la raison de l'utilisation des noms de table abrégés était une limitation DB2 (nous avions DB2 sous z / os et SQL Server) de 18 caractères pour les tables et les colonnes. J'ai rapidement souligné que cela était inexact avec la documentation du site IBM. Ils ont ensuite déclaré qu'il s'agissait d'un problème COBOL (oui, ils étaient activement développés COBOL) au cas où il aurait besoin de parler à la base de données qui a ensuite été réfutée par les jockeys MF. Enfin, leur réponse a été que c'est notre norme de publication.

Nous avons demandé au comité des normes d'augmenter la longueur de 18 à 32 caractères et avons reçu une limite de 30 caractères. Cela a entraîné des tables allant des noms inutiles de 'SR_M_DLY_ADV_PRD_S' à 'IDX_FDSHRCLAS_LIF_RTRN_STATS_X' FML

Ainsi, au cours de ma douzaine d'années d'expérience, les noms de table raccourcis n'offrent aucun avantage tangible et entraînent un coût de développement et de maintenance plus élevé, car je dois toujours me référer aux dictionnaires de données pour traduire les déchets à l'écran en un identifiant significatif. Ce qui peut être contrasté avec des entités logiquement nommées avec lesquelles j'ai travaillé et qui peuvent principalement être recréées à partir de la mémoire car elles ont été nommées de manière intuitive.

C'est une habitude (je suis d'accord avec Kevinsky). C'était une réaction à certains problèmes anciens (peut-être existants) à la restriction (longueur du nom, espace entre les mots de noms complexes, multilingue, etc.) du système d'exploitation (DOS, Windows, par exemple) et de certains logiciels qui ne géraient pas ces noms. Des personnes expérimentées ont déclaré: "Faites-le (utilisez des noms courts et séparés avec des noms soulignés) et tout irait bien."

J'aime utiliser des noms descriptifs pour les raisons susmentionnées par des affiches.

Mais il y a aussi un autre avantage. Par exemple, avec un nom descriptif, il vous permet d'utiliser des noms imbriqués. Supposons que vous ayez une table appelée Employé. Si vous avez une relation avec une autre table, elle pourrait s'appeler EmployeeAddress. Ou EmployeeDepartment. Avec le nommage cryptique et abrégé, cela est presque impossible.

Dépend de la complexité des définitions sous-jacentes de chaque colonne. Je pense que les gens deviennent paresseux avec la gestion des métadonnées lorsqu'ils voient ce genre de noms de colonne très descriptifs, et ce sont même des descriptions incomplètes. Vous pourriez aussi bien demander pourquoi abréger quoi que ce soit.