Pourquoi les noms de table / colonne / index Oracle sont-ils limités à 30 caractères?
Je peux comprendre qu'il y a de nombreuses années, il y avait ce genre de limitation, mais de nos jours, cette limite pourrait facilement être 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 en nommant des clés étrangères.
Est-ce que quelqu'un sait réellement pourquoi ce n'est pas une plus grande taille - ou est-il plus grand en 11g?
Apparemment, la réponse est que cela va casser actuellement les scripts 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 la mort de mille coupes.
Chaque fois que je vois ce genre d'objection à l'interne, je pense qu'il est temps de mordre la balle et de régler le problème. Si des personnes exécutent des scripts qu'elles ne vérifient ni ne maintiennent pas lors de la mise à niveau de versions Oracle, laissez-les subir les conséquences de ce choix. Fournissez-leur un indicateur de compatibilité, jusqu'à la taille de 4 000, puis épargnez-moi le temps perdu lorsque je crée des objets. Il faut constamment compter jusqu'à 30 pour vérifier que le nom est "OK".
Je crois que c'est la norme ANSI.
EDIT:
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 la prend pas encore en charge (ou l’a partiellement prise en charge, dans la mesure où elle 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écoule de la norme SQL (historiquement, je soupçonne que la décision d'Oracle a conduit à la norme SQL, car Oracle était antérieure à la normalisation de SQL), je parierais qu'une grande partie de la réticence d'autoriser des identificateurs plus longs provient de la réalisation qu'il existe des millions d'administrateurs de base de données avec des millions de scripts personnalisés qui supposent tous que les identificateurs ont une longueur de 30 caractères. Permettant 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 ...
briser soudainement parce que la DBA d’il ya 15 ans utilisait VARCHAR2 (30) plutôt que DBA_TABLES.TABLE_NAME%TYPE dans le script provoquerait une révolte massive. Je parierais qu'Oracle à lui seul compte des milliers d'endroits où ce genre de chose a été fait au fil des ans dans divers packages et composants. La mise à niveau de tout ce code existant pour prendre en charge des identifiants plus longs constituerait un projet formidable qui générerait presque certainement des coûts supplémentaires en termes de temps de développement, de contrôle de la qualité et nouvellement introduit. bugs que cela générerait des avantages.
Je cherchais cela et trouvais cette question via Google, mais découvris aussi que depuis 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 administrateur de base de données ou développeur aura atteint un point où la limite de 30 caractères pour les noms d'objet est à l'origine d'un problème. Cette limite peut être extrêmement pénible lors 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.
Ceci est une nouvelle fonctionnalité de la version 12.2, selon ( http://blog.dbi-services.com/Oracle-12cr2-long-identifiers/ ). Selon ce billet, 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-0A8C9E9F875C )
Depuis Oracle Database 12c Release 2 (12.2), la longueur maximale des noms d'identificateur 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 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 aux autres, 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 vont avoir besoin de plus de préfixes et de suffixes, ce qui limite encore la longueur des noms de table.
Les violations de contrainte sont signalées dans SQLERRM, limité à 255 caractères, et utilisé par la plupart des clients pour rendre les erreurs visibles. Je soupçonne qu'une augmentation de la taille autorisée des noms de contrainte aurait un impact significatif sur la capacité à signaler les violations (en particulier lorsqu'une violation de contrainte a été signalée à travers quelques couches de code PL/SQL).
Je crois que la longueur de 30 caractères d'identification provient de COBOL qui a été normalisé à la fin des années 1950. Comme les programmes COBOL étaient le principal utilisateur de SQL (et SEQUEL auparavant (et QUEL auparavant)), cela devait sembler être un nombre raisonnable pour la longueur de l'identificateur.
Toutes ces "contraintes" restent les réponses aux limitations imposées par les architectures de processeur des années 70. Depuis lors, les processeurs ont évolué au point que ces limitations ne sont plus nécessaires; ils sont juste laissés. Cependant, les changer est un gros contrat pour les rédacteurs du SGBDR. Etant donné que ces limites de longueur affectent tout ce qui se passe en aval, il est malencontreux d’admettre qu’un nom de procédure plus long peut et va probablement casser 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 anciennes dans lesquelles 30 semblaient énormément, et beaucoup plus aurait augmenté le risque de supprimer le cache du dictionnaire de la mémoire réelle dans des bases de données classiques.
En revanche, ODBC namespace 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 en construisant automatiquement des tables de base de données avec des noms de colonne extraits des en-têtes de table de feuille. Cela vous conduit à autoriser des identificateurs contenant même des retours chariot incorporés, ainsi que des caractères spéciaux et des casse mixtes, ce qui est une abstraction judicieuse, car elle modélise la façon de penser des analystes de données actuels.
Peu importe SQL92, c’est la conformité ODBC qui compte vraiment pour la base de données universelle d’aujourd’hui, et d’autres éditeurs le résout mieux que Oracle. Même Teradata, par exemple, qui n’est pas perçu comme omniprésent player, s'adresse à DEUX espaces de noms, avec et sans guillemets, le premier avec une limite de 30 caractères, le dernier avec une implémentation complète ODBC) dans laquelle des identificateurs longs et étranges sont pris en compte.
Même dans l'arène traditionnelle des grandes bases de données, 30 caractères posent souvent un problème, car les noms doivent rester significatifs, cohérents et mémorables. Une fois que vous commencez à concevoir des structures spécialisées avec l'héritage nommé par le rôle, vous commencez à abréviation des abréviations. La cohérence disparaît rapidement car, par exemple, le même identifiant racine rendu sous forme de nom de table ou de colonne nécessitera dans un cas une abréviation supplémentaire, mais pas dans l'autre. . Si de vrais utilisateurs en nombre important sont invités à de telles couches, la facilité d'utilisation en résultera, et heureusement, pour toute base de données vieillissante, le principal objectif est maintenant de séparer l'utilisateur de la base de données via des couches d'objet et des outils de BI.
Cela laisse la couche base de données aux équipes DBA et architecte de données, qui ne sont peut-être pas dérangées. Élaborer des abréviations est toujours un travail pour la vie, semble-t-il.
Le fait qu’Oracle n’ait pas remédié à cette ancienne limitation tient peut-être surtout au fait qu’elle ne perd pas (encore) beaucoup d’activités au profit de ses concurrents alors qu’elle ne peut pas porter directement les conceptions de base de données construites à l’aide d’identifiants plus longs.
Tous les commentaires ci-dessus sont exacts, MAIS vous devez garder à l'esprit le coût de performance des noms plus longs. Au début des années 1990, lorsque Informix a mis en place un énorme panneau publicitaire "Informix Faster Than Oracle!" sur la route 101 à côté du siège d'Oracle, Informix n'autorisait que les noms de table de moins de 18 caractères! La raison en est évidente - les noms de table dans leur forme littérale (c'est-à-dire sous la forme de noms réels plutôt que 't138577321' ou quelque chose comme ça) sont stockés dans le dictionnaire de données. Les noms plus longs correspondent à 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 syntaxique difficile, un dictionnaire de données plus volumineux est synonyme de performances médiocres ...