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

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

Est-ce que quelqu'un sait réellement pourquoi ce n'est pas une plus grande taille - ou est-ce plus gros en 11g?


Apparemment, la réponse est qu'il va casser les scripts actuellement qui ne sont pas codés défensivement. Je dis 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 va mourir la mort d'un millier de coupes.

Chaque fois que je vois ce genre d'objection en interne, je pense qu'il est temps de mordre la balle et de le régler. Si des personnes exécutent des scripts qu'elles ne vérifient pas ou ne gèrent pas lorsqu'elles mettent à niveau des versions D'Oracle, laissez-les subir les conséquences de ce choix. Leur fournir un drapeau de compatibilité, jusqu'à la taille à 4000, puis économisez-moi le temps perdu lorsque je crée des objets d'avoir à compter constamment jusqu'à 30 pour vérifier que le nom est 'OK'.

139
demandé sur Chris Gill 2009-09-04 13:20:06

10 réponses

Je crois que c'est la norme ANSI.

Modifier:

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 supporte pas encore (ou a un support partiel pour cela, dans la mesure où il permet 30 caractères. Hmmm.)

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

(recherche d'une référence)

65
répondu cagcowboy 2009-09-04 10:41:25

En plus du point de cagcowboy qu'il dérive de la norme SQL (historiquement, je soupçonne que la décision D'Oracle conduit à la norme 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 provient de la prise de conscience qu'il y a des millions de DBA avec des millions de scripts personnalisés qui supposent tous que les identifiants ont 30 caractères. Autoriser chaque ligne de code qui va quelque chose comme

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

Casser soudainement parce que le DBA il y a 15 ans utilisait VARCHAR2 (30) plutôt que DBA_TABLES.TABLE_NAME%TYPE dans le script provoquerait une révolte massive. Je parierais que seul Oracle a des milliers d'endroits où ce genre de chose a été fait au fil des ans dans divers paquets et composants. La modification de tout ce code existant pour prendre en charge des identifiants plus longs serait un projet formidable qui générerait presque certainement way Plus de coûts en temps de développeur, en temps D'assurance qualité et en temps nouveau introduit des bugs que cela générerait des avantages.

42
répondu Justin Cave 2009-09-04 10:12:56

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 douloureuse lorsque vous effectuez des projets de migration de SQL Server ou MySQL vers Oracle. Dans Oracle Base de données 12cR2, la longueur maximale de la plupart des identifiants est maintenant de 128 caractères.

Ceci est une nouvelle fonctionnalité dans 12.2, selon ( http://blog.dbi-services.com/oracle-12cr2-long-identifiers/). Selon ce post, 12.1 était encore 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)

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

10
répondu Kanmuri 2016-12-30 21:14:13

Compte tenu de la nécessité pratique de limiter la longueur des identificateurs, une bonne conception limite la longueur des noms réels pour éviter de heurter 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 nommage 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, limitant davantage la longueur des noms de table.

6
répondu Lorenzo Gatti 2013-04-10 16:15:01

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é de signaler les violations (en particulier lorsqu'une violation de contrainte a été générée à travers quelques couches de code PL/SQL).

5
répondu Gary Myers 2009-09-04 23:43:28

Je crois que la longueur d'Identificateur de 30 caractères provient de COBOL qui a été standardisé à la fin des années 1950. puisque les programmes COBOL étaient l'utilisateur principal de SQL (et SEQUEL avant cela (et QUEL avant cela)), cela a dû sembler un nombre raisonnable pour la longueur d'identificateur.

4
répondu Michael Dillon 2009-10-15 13:30:59

Toutes ces "contraintes" sont laissées sur les 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; elles sont simplement laissées de côté. Cependant, les Changer est un gros problème pour les rédacteurs du SGBDR. Puisque ces limitatons de longueur affectent tout en aval le changer bon gré mal gré pour accueillir disons un nom de procédure plus long peut et va probablement casser beaucoup d'autres choses tels que les rapports d'exécution, le dictionnaire de données, etc., ainsi de suite et ainsi de suite. J'aurais besoin d'une réécriture majeure du SGBDR Oracle.

4
répondu Mac 2013-10-09 14:16:52

La réponse directe à la question Est que le style Oracle est hérité d'idées plus anciennes dans lesquelles 30 semblait beaucoup, et beaucoup plus aurait augmenté le risque de décompresser 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 colonnes tirés des en-têtes de table de feuille. Penser comme cela vous conduit à autoriser des identifiants qui contiennent même des retours chariot intégrés, et bien sûr des caractères spéciaux et des cas mixtes. 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 abordé cela mieux 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 le citations, le premier avec une limite de 30 caractères, le second une implémentation ODBC complète où des identifiants longs étranges sont pris en charge.

Même dans l'arène traditionnelle des grandes bases de données, 30 caractères est souvent un problème où 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 bientôt, car par exemple le même identifiant racine rendu comme un nom de table ou un le nom de la colonne aura dans un cas besoin d'une abréviation supplémentaire et dans l'autre pas. Si de vrais utilisateurs en nombre significatif sont invités à de telles couches, les conséquences sont très mauvaises, et heureusement pour toute base de données vieillissante, le lecteur principal est maintenant de séparer l'utilisateur de la base de données via des couches d'objets et des outils BI.

Cela laisse la couche de base de données aux équipes DBA et Data architect, qui ne sont peut-être pas si dérangées. Travailler abréviation régimes est toujours un travail pour la vie, il sembler.

Que Oracle n'a pas abordé cette ancienne limitation reflète peut-être principalement sur le fait qu'il ne perd pas (encore) beaucoup d'affaires à sa concurrence quand il ne peut pas porter directement des conceptions de base de données construites en utilisant des identifiants plus longs.

2
répondu atconsul 2015-04-08 14:27:50

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 1990, lorsque Informix mis en place énorme panneau d'affichage " Informix plus rapide que Oracle!"sur la route 101 à côté du siège D'Oracle, Informix n'autorisait les noms de table que de moins de 18 caractères! La raison en est évidente - les noms de table dans leur forme littérale (c'est-à-dire en tant que noms réels plutôt que 't138577321 ou quelque chose comme ça) sont stockés dans le dictionnaire de données. Noms plus longs égaux plus grands Dictionnaire de données, et puisque le dictionnaire de données est lu chaque fois qu'une requête nécessite une analyse en dur, un dictionnaire de données plus grand équivaut à de mauvaises performances...

1
répondu Raphael 2013-12-27 20:48:16

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 des 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

-6
répondu user173422 2010-08-03 11:21:00