La respuesta directa a la pregunta es que el estilo de Oracle se hereda de ideas antiguas en las que 30 parecían mucho, y mucho más habría aumentado el riesgo de desanclar el caché del diccionario de la memoria real en bases de datos típicas.
Por el contrario, el espacio de nombres ODBC proviene de un lugar muy diferente, donde los conjuntos de datos se extraen rápidamente analizando una tabla en una hoja de Excel y construyen automáticamente tablas de bases de datos con nombres de columna tomados de los encabezados de las tablas. Pensar así te lleva a permitir identificadores que incluso contienen retornos de carro incrustados y, por supuesto, caracteres especiales y mayúsculas y minúsculas. Es una abstracción sensata porque modela la forma en que piensan los analistas de datos actuales.
No importa SQL92, es el cumplimiento de ODBC lo que realmente importa para la base de datos universal de hoy en día, y otros proveedores lo han abordado mejor que Oracle. Incluso Teradata, por ejemplo, que no es visto por muchos como un jugador dominante, atiende a DOS espacios de nombres, con y sin comillas, el primero con un límite de 30 caracteres, el último una implementación completa de ODBC donde se atienden identificadores largos extraños .
Incluso en el campo tradicional de grandes bases de datos, 30 caracteres es a menudo un problema donde los nombres deben permanecer significativos, consistentes y memorables. Una vez que comienza a diseñar estructuras especializadas con herencia con nombre de rol, comienza a abreviar abreviaturas, y la consistencia pronto muere, porque, por ejemplo, el mismo identificador de raíz representado como un nombre de tabla o un nombre de columna en un caso necesitará más abreviaturas y en el otro no . Si se invita a usuarios reales en cantidades significativas a tales capas, las consecuencias son una usabilidad muy pobre, y afortunadamente para cualquier base de datos antigua, la unidad principal ahora es separar al usuario de la base de datos a través de capas de objetos y herramientas de BI.
Esto deja la capa de la base de datos al DBA y a los equipos de arquitectos de datos, que tal vez no estén tan molestos. Al parecer, elaborar esquemas de abreviaturas sigue siendo un trabajo para toda la vida.
El hecho de que Oracle no haya abordado esta antigua limitación quizás se deba principalmente al hecho de que (todavía) no está perdiendo mucho negocio ante su competencia cuando no puede portar directamente los diseños de bases de datos creados con identificadores más largos.