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.