Pourquoi les noms de table / colonne / index Oracle sont-ils limités à 30 caractères?


149

Je peux comprendre qu'il y avait de nombreuses années ce genre de limitation, mais de nos jours, cette limite pourrait certainement être facilement augmentée. Nous avons des conventions de dénomination pour les objets, mais il y a toujours un cas où nous atteignons cette limite - en particulier pour nommer les clés étrangères.

Est-ce que quelqu'un sait vraiment pourquoi ce n'est pas une taille plus grande - ou est-elle plus grande en 11g?


Apparemment, la réponse est que cela cassera les scripts actuellement qui ne sont pas codés de manière défensive. Je dis que c'est une chose très inquiétante, Oracle essaie d'être la base de données, c'est sûrement le genre de chose que vous devez constamment améliorer, sinon votre produit mourra de mille coupures.

Chaque fois que je vois ce genre d'objection en interne, je pense qu'il est temps de mordre la balle et de régler le problème. Si des utilisateurs exécutent des scripts qu'ils ne vérifient pas ou ne gèrent pas lorsqu'ils mettent à niveau les versions d'Oracle, laissez-les subir les conséquences de ce choix. Fournissez-leur un indicateur de compatibilité, jusqu'à 4000, puis évitez de perdre du temps lorsque je crée des objets à compter constamment jusqu'à 30 pour vérifier que le nom est «OK».


3
Puisqu'il doit y avoir une limite? Faites-en 64 caractères et vous trouverez probablement quelqu'un qui vous demande pourquoi ce n'est pas 128 etc. Combien de temps dure un morceau de chaîne?
Le président du

45
C'est vrai, mais 30 est un morceau de corde très court. Pourquoi ne peut-il pas être de 4000 - la taille d'un Varchar2 - Oracle se soucie-t-il vraiment de la durée une fois qu'il a analysé la requête?
Chris Gill

22
@TheChairman PostgreSQL me limite à 63 caractères, et je n'ai jamais eu de problème avec cette limite de longueur. Il est suffisamment grand pour que mes noms tiennent, et si j'envisage un nom plus long, il est temps de commencer à penser à l'impact négatif sur la lisibilité. D'un autre côté, je rencontre souvent des limites de longueur de nom dans Oracle et je suis obligé de réduire la lisibilité de mon nom en raison de la limite de 30 caractères. Quelques personnes pourraient se plaindre d'une limite de 64, mais beaucoup de gens ont déjà des problèmes à cause de la limite de 30 caractères. Il s'agit de répondre à 99% des cas d'utilisation, et Oracle échoue ici.
jpmc26

1
Allez, Oracle, tu es devenu un dinosaure! Microsoft fait du bon travail pour rendre le serveur SQL plus convivial. Relâchez maintenant la restriction de longueur de nom.
user3454439

1
Avance rapide vers Oracle 12cR2, c'est maintenant 128 octets au lieu de 30 :-) docs.oracle.com/en/database/oracle/oracle-database/12.2/newft
Stefan L

Réponses:


71

Je crois que c'est la norme ANSI.

ÉDITER:

En fait, je pense que c'est la norme SQL-92.

Une version ultérieure de la norme semble autoriser éventuellement 128 noms de caractères, mais Oracle ne le prend pas encore en charge (ou en a une prise en charge partielle, dans la mesure où il autorise 30 caractères. Hmmm.)

Recherchez "F391, identificateurs longs" sur cette page ... http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/ap_standard_sql001.htm

(Recherche d'un ref)


1
Hmm, ce n'est pas ainsi que j'ai lu ce document. Il me dit que F391 est un élément dans la spécification SQL / Foundation (quoi que ce soit), et qu'Oracle a un support partiel pour cela, avec une limite de 30 caractères.
skaffman le

21
Conformité partielle. Quelle blague. "nos vis sont partiellement conformes aux normes métriques, sauf qu'elles ne sont pas métriques."
Jens Schauder

5
Je n'ai pas lu la spécification F391 en détail, mais je suppose (peut-être à tort) que "Long identifiers" signifie une augmentation de la longueur de l'identifiant de 30 à 128. Donc, dire que vous le supportez "partiellement" en autorisant 30 caractères, c'est un peu effronté. Vous ne supportez pas la nouvelle norme, vous supportez toujours l'ancienne norme (bien que 25% du chemin vers la nouvelle norme) Est-ce que cela avait du sens? !!?
cagcowboy le

7
Le standard SQL-92 est ici contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt , mais si vous lisez la section "17.1 Description des zones de descripteur d'élément SQL", il est indiqué que les identifiants comme les noms et les schémas doivent autoriser au moins 128 personnages.
Rick

46
Le fait même que les fans d'Oracle ne voient pas l'utilité de plus de 30 identificateurs de caractères est dérangeant. "Rendez vos noms significatifs / descriptifs, utilisez des traits de soulignement au lieu de la casse de chameau et restez sous 30 caractères". Cela ne dépasserait jamais 30 caractères. Amirite? Plus comme abréger vos abréviations et quand aucun des noms n'a de sens, passez toute la journée à lire / mettre à jour la documentation.
Adam Jones

45

En plus de l'argument de cagcowboy selon lequel il dérive du standard SQL (historiquement, je soupçonne que la décision d'Oracle a conduit au standard SQL puisque Oracle a précédé la standardisation de SQL), je parierais qu'une grande partie de la réticence à autoriser des identifiants plus longs vient de la prise de conscience qu'il existe des millions de DBA avec des millions de scripts personnalisés qui supposent tous que les identifiants comportent 30 caractères. Autoriser chaque ligne de code qui ressemble à quelque chose comme

  l_table_name VARCHAR2(30);
BEGIN
  SELECT table_name
    INTO l_table_name
    FROM dba_tables
   WHERE ...

briser soudainement parce que le DBA il y a 15 ans utilisé VARCHAR2 (30) plutôt que DBA_TABLES.TABLE_NAME%TYPEdans le script provoquerait une révolte massive. Je parierais qu'Oracle à lui seul a des milliers d'endroits où ce genre de chose a été fait au fil des ans dans divers packages et composants. La modernisation de tout ce code existant pour prendre en charge des identifiants plus longs serait un projet énorme qui générerait presque certainement des coûts beaucoup plus élevés en temps de développeur, en temps de contrôle qualité et en bogues nouvellement introduits qu'il ne générerait d'avantages.


13
+1 C'est presque certainement l'un des nombreux paralysés de la conception héritée d'Oracle.
skaffman le

43
Il est sûrement temps de développer une paire et de l'augmenter - ajoutez un indicateur pour que les administrateurs de base de données puissent le raffiner à 30. Les problèmes hérités comme celui-ci devraient toujours être confrontés et triés, sinon vous finirez par paralyser toute la base de code, et les gens vont simplement bouger sur quelque chose d'autre
Chris Gill

6
Pas seulement des millions de lignes de code écrit par DBA, mais aussi beaucoup de code interne d'Oracle. Ce sujet a été abordé lors d'une session avec Steven Feuerstein et il a dit qu'il ne pensait pas qu'ils le changeraient un jour.
Matthew Watson

10
Ils ne pouvaient pas non plus le présenter comme une nouvelle fonctionnalité ... ils passeraient beaucoup de temps à étendre la limite, puis annonceraient "vous pouvez maintenant utiliser des noms de plus de 30 caractères!". Ils seraient la risée.
skaffman

9
Si vous utilisez encore des scripts vieux de 15 ans, quelque chose ne va pas . En outre, les réparer serait un coût unique (éventuellement avec un peu plus pour la maintenance continue), tandis que les développeurs continueront à perdre du temps inutilement à créer des noms horriblement abrégés indéfiniment. @skaffman Ils sont déjà la risée de ne pas le réparer (et une foule d'autres décisions de conception qui sont pathétiques à l'ère moderne, comme aucun type booléen ou auto-incrémenté), en ce qui me concerne.
jpmc26

11

Je cherchais cela et j'ai trouvé cette question via Google, mais j'ai également découvert qu'à partir d'Oracle 12c Release 2 (12.2), ce n'est plus strictement le cas. ( https://oracle-base.com/articles/12c/long-identifiers-12cr2 )

À un moment donné, chaque DBA ou développeur aura atteint un point où la limite de 30 caractères pour les noms d'objets a causé un problème. Cette limite peut être extrêmement pénible lors de la réalisation de projets de migration de SQL Server ou MySQL vers Oracle. Dans Oracle Database 12cR2, la longueur maximale de la plupart des identificateurs est désormais de 128 caractères.

Il s'agit d'une nouvelle fonctionnalité de la version 12.2, selon ( http://blog.dbi-services.com/oracle-12cr2-long-identifiers/ ). Selon ce post, 12.1 était toujours limité à 30 caractères.


Edit: Voici un lien vers la documentation officielle d'Oracle expliquant le changement. ( https://docs.oracle.com/cloud/latest/exadataexpress-cloud/CSDBF/longer-identifier-names.htm#CSDBF-GUID-F4CA155F-5A37-4705-8443-0A8C9E3F875C )

À partir d'Oracle Database 12c Release 2 (12.2), la longueur maximale des noms d'identifiant pour la plupart des types d'objets de base de données a été augmentée à 128 octets.


128 octets / 4 octets (Unicode) = 32 caractères. Au moins, je crois comprendre que 4 octets pour les caractères non Unicode n'est-ce pas rare? Je dois me demander si cela signifie simplement qu'ils prennent en charge Unicode maintenant? Tout comme VARCHAR2(2)ne signifie pas 2 caractères mais 2 octets.
Seth le

1
Je vois votre point de vue, mais les caractères par rapport aux octets dépendent du jeu de caractères de votre base de données. Ce paramètre détermine le codage pour les types de données char (tels que varchar2) ainsi que le codage pour les identificateurs de base de données. Cela contraste avec le jeu de caractères national, qui est utilisé pour les types de données nchar. Donc oui, si vous avez un encodage tel que vos identifiants utilisent 4 octets par caractère (en supposant que cela puisse être utilisé comme jeu de caractères DB), vous en auriez maintenant 32 au lieu de 7. Mais je pense que pour la plupart des cas d'utilisation, les identifiants seraient caractères à un octet.
Kanmuri

6

Compte tenu de la nécessité pratique de limites de longueur d'identifiant, une bonne conception limite la longueur des noms réels pour éviter de toucher le plafond lorsque les noms sont combinés les uns avec les autres et avec des préfixes et des suffixes.

Par exemple, une convention de dénomination des contraintes de clé étrangère

FK_<table1>_<table2> 

limite les noms de table à 13 caractères ou moins; la plupart des bases de données auront besoin de plus de préfixes et de suffixes, ce qui limitera davantage la longueur des noms de table.


5

Les violations de contraintes sont signalées dans SQLERRM qui est limité à 255 caractères et que la plupart des clients utilisent pour rendre les erreurs visibles. Je soupçonne que l'augmentation de la taille autorisée des noms de contraintes aurait un impact significatif sur la capacité à signaler les violations (en particulier lorsqu'une violation de contrainte a été remontée à travers quelques couches de code PL / SQL).


Alors, euh, élargissez cette table, alors?
skaffman

2
Ce n'est pas une table, mais comment le logiciel client obtient réellement des erreurs de la base de données.
Gary Myers

@skaffman SQLERRM length est une spécification API / ABI. Changer cela signifierait devoir patcher tous les pilotes OCI de la planète (sinon dépassement de tampon). Ils pourraient placer le changement sur le client pour augmenter le buflen dans OCI 13 d'abord et le serveur dans quelque chose comme Oracle 15, où les clients OCI 10 ne seraient plus pris en charge, je suppose. (Peut-être qu'ils envisagent même de le faire maintenant, mais les versions majeures d'Oracle ne sortent que toutes les quelques années; et ensuite, nous pouvons encore rencontrer des problèmes de mise à niveau de script / application lorsque les applications sont migrées vers un serveur / client différent).
cowbert

4

Je crois que la longueur de l'identifiant de 30 caractères provient de COBOL qui a été normalisé à la fin des années 1950. Puisque les programmes COBOL étaient le principal utilisateur de SQL (et SEQUEL avant cela (et QUEL avant cela)), cela devait sembler être un nombre raisonnable pour la longueur de l'identifiant.


5
Je crois que la première version d'Oracle a été écrite en Fortran, qui, je pense, a une limite de longueur d'identifiant de 31. C'est peut-être pertinent.
David Aldridge

4

Toutes ces `` contraintes '' sont laissées au-dessus des réponses aux limitations imposées par les architectures de processeurs datant des années 70. Depuis lors, les processeurs ont évolué au point que ces limitations ne sont plus nécessaires; ils sont juste restés. Cependant, les changer est une grosse affaire pour les auteurs du SGBDR. Étant donné que ces limites de longueur affectent tout ce qui change en aval, il est inutile de s'adapter à un nom de procédure plus long peut et probablement brisera beaucoup d'autres choses telles que les rapports d'exception, le dictionnaire de données, etc., etc. J'aurais besoin d'une réécriture majeure du SGBDR Oracle.


2

La réponse directe à la question est que le style Oracle est hérité d'idées plus anciennes dans lesquelles 30 semblaient beaucoup, et beaucoup plus aurait augmenté le risque de désépingler le cache du dictionnaire de la mémoire réelle dans les bases de données typiques.

En revanche, l'espace de noms ODBC provient d'un endroit très différent, où les ensembles de données sont extraits rapidement en analysant une table dans une feuille Excel et construisent automatiquement des tables de base de données avec des noms de colonne tirés des en-têtes de table de feuille. Penser ainsi vous amène à autoriser des identifiants qui contiennent même des retours chariot intégrés, et bien sûr des caractères spéciaux et des casse mixte. C'est une abstraction sensée car elle modélise la façon dont les analystes de données d'aujourd'hui pensent.

Peu importe SQL92, c'est la conformité ODBC qui compte vraiment pour la base de données universelle d'aujourd'hui, et d'autres fournisseurs ont mieux traité ce problème qu'Oracle. Même Teradata, par exemple, qui n'est pas considéré par beaucoup comme un joueur omniprésent, s'adresse à DEUX espaces de noms, avec et sans les guillemets, le premier avec une limite de 30 caractères, le second une implémentation ODBC complète où de longs identifiants étranges sont pris en charge. .

Même dans l'arène traditionnelle des grandes bases de données, 30 caractères sont souvent un problème lorsque les noms doivent rester significatifs, cohérents et mémorables. Une fois que vous commencez à concevoir des structures spécialisées avec un héritage nommé par rôle, vous commencez à abréger les abréviations, et la cohérence meurt rapidement, car par exemple, le même identifiant racine rendu sous forme de nom de table ou de nom de colonne nécessitera dans un cas une abréviation supplémentaire et dans l'autre pas . Si de vrais utilisateurs en nombre significatif sont invités sur de telles couches, les conséquences sont une très mauvaise utilisabilité, et heureusement pour toute base de données vieillissante, le principal moteur est maintenant de séparer l'utilisateur de la base de données via des couches d'objets et des outils de BI.

Cela laisse la couche de base de données au DBA et aux équipes d'architectes de données, qui ne sont peut-être pas si dérangées. L'élaboration de schémas d'abréviation est toujours un travail à vie, semble-t-il.

Le fait qu'Oracle n'ait pas abordé cette ancienne limitation s'explique peut-être principalement par le fait qu'il ne perd pas (encore) beaucoup d'activité face à ses concurrents lorsqu'il ne peut pas porter directement les conceptions de bases de données construites à l'aide d'identifiants plus longs.


Pas à Oracle. ODBC est un bébé Microsoft, pas un Java. Il s'agit toujours d' une bibliothèque d'aide distincte liée à OCI (regardez comment instantclient est déployé - pour que ODBC fonctionne avec instantclient, vous avez besoin à la fois du pilote OCI et des zips instantclient ODBC). La principale plate-forme client d'Oracle (en plus de l'ancienne version Pro * C / C / C ++) est JDBC, qui est directement liée à OCI, et non à ODBC.
cowbert

1

Tous les commentaires ci-dessus sont corrects, MAIS vous devez garder à l'esprit le coût de performance des noms plus longs. Au début des années 90, quand Informix a installé un énorme panneau d'affichage "Informix Faster Than Oracle!" sur la route 101 à côté du siège d'Oracle, Informix n'autorisait que des noms de table inférieurs à 18 caractères! La raison est évidente - les noms de table dans leur forme littérale (c'est-à-dire sous forme de noms réels plutôt que «t138577321» ou quelque chose comme ça) sont stockés dans le dictionnaire de données. Des noms plus longs équivalent à un dictionnaire de données plus volumineux, et comme le dictionnaire de données est lu chaque fois qu'une requête nécessite une analyse difficile, un dictionnaire de données plus volumineux équivaut à de mauvaises performances ...


7
Il n'y a absolument aucune raison pour que la correspondance exacte de chaînes courtes soit un goulot d'étranglement dans un logiciel moderne, sauf si vous le faites des milliards de fois - ce qui n'est pas le cas dans l'analyse des requêtes. Les considérations relatives à la taille et aux performances peuvent avoir été importantes lors de la conception de cette partie d'Oracle, mais elles ne sont pas vraiment pertinentes de nos jours.
Sarah G

-7

ok, la limitation existe ....

mais avez-vous vraiment besoin de plus de 30 caractères pour nommer une table / index / colonne ??

lors de l'écriture de requêtes, avec cette limitation, je trouve toujours certains noms de colonnes / tables ennuyeux. Si la limite était plus élevée, je pourrais rencontrer des tables qui nécessitaient une requête comme:

select unique_identifier_column, 
time_when_the_user_remembered_to_change_the_row_in_the_receipt_table, 
foreign_key_to_the_ap_invoice_distributions_history_table_related_to_the_all_rows_table 
from ap_invoices_really_really_all_all_rows_present_in_this_ebs_table.

Je m'excuse pour les mots énormes: P


29
Ce serait bien de pouvoir nommer les clés étrangères avec les noms des tables et des colonnes qu'elles rejoignent - par conséquent, lorsqu'une exception de clé étrangère est lancée, vous n'avez pas à rechercher les colonnes qui ont causé l'échec. Encore une fois, Oracle pourrait simplement vous dire cette info ...
Chris Gill

10
Il y a de nombreuses raisons pour lesquelles nous avons besoin de plus de 30 caractères, bien que généralement 30 caractères suffisent. Parfois, un nom de table doit être suffisamment détaillé pour être significatif. Par exemple, j'ai cette table appelée sch_PatternRunTimeException, elle fait exactement 30 caractères. Maintenant, je dois ajouter un appel de table de mise en miroir sch_DevPatternRunTimeException. Cette norme de dénomination à 3 caractères supplémentaires ne fonctionne pas pour Oracle, MSSQL n'a aucun problème. Cela m'oblige à trouver un nouveau nom. Renommer la table est faisable, mais cela aura un impact sur les opérations de nos clients, ce que nous essayons d'éviter.
dsum

6
Si dans 99,9% des cas possibles +30 caractères sont ennuyeux, cela ne veut pas dire qu'ils seraient utiles les 0,1% restants.
René Nyffenegger

14
Ahhh l'argument de la pente glissante. Une limite de seulement 4 caractères alphanumériques nous donnerait plus de 1 million de combinaisons de tables, donc personne n'a vraiment besoin de plus de 4. Pourtant, nous y sommes. Et ce n'est pas vraiment 30 caractères, c'est moins de 30 caractères puisque ma convention de dénomination de casse pascal doit être vidée avec le manque de sensibilité à la casse et remplacée par des noms délimités par des traits de soulignement. Combinez cela avec divers préfixes / suffixes et vous avez la chance d'avoir même 20 caractères. Qui ne préférerait pas qu'un nom d'index robuste fasse écho avec une erreur de violation sur un méli-mélo d'abréviations et de traits de soulignement?
b_levitt

Il est convenu que cela ne résout pas le problème. Normalement, les êtres humains n'ont pas besoin de noms de colonnes plus longs, mais il existe de nombreux cas où les noms d'objets sont générés automatiquement.
fool4jesus
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.