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

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».

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)

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.

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.

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.

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).

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.

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.

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.

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

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