¿Por qué los nombres de tabla / columna / índice de Oracle están limitados a 30 caracteres?

Puedo entender que hace muchos años habría este tipo de limitación, pero hoy en día seguramente este límite podría aumentarse fácilmente. Tenemos convenciones de nomenclatura para objetos, pero siempre hay un caso que aparece cuando alcanzamos este límite, especialmente al nombrar claves foráneas.

¿Alguien sabe realmente por qué este no es un tamaño más grande, o es más grande en 11 g?

Aparentemente, la respuesta es que romperá los scripts actuales que no están codificados a la defensiva. Digo que es algo muy preocupante, Oracle está tratando de ser la base de datos, seguramente este es el tipo de cosas que debe mejorar constantemente, de lo contrario su producto morirá la muerte de mil cortes.

Cada vez que veo este tipo de objeción internamente, creo que es hora de morder la bala y resolverla. Si las personas ejecutan secuencias de comandos que no comprueban o mantienen cuando actualizan las versiones de Oracle, entonces dejen que sufran las consecuencias de esa elección. Proporcione un indicador de compatibilidad, aumente el tamaño a 4000, luego ahórreme el tiempo perdido cuando estoy creando objetos de tener que contar constantemente hasta 30 para verificar que el nombre esté 'OK'.

Creo que es el estándar ANSI.

EDITAR:

En realidad, creo que es el estándar SQL-92.

Una versión posterior del estándar parece permitir opcionalmente 128 nombres de caracteres, pero Oracle aún no admite esto (o tiene soporte parcial para él, en la medida en que permite 30 caracteres. Hmmm).

Busque "F391, identificadores largos" en esta página ... http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/ap_standard_sql001.htm

(Buscando una referencia)

Además del punto de cagcowboy de que deriva del estándar SQL (históricamente, sospecho que la decisión de Oracle condujo al estándar SQL ya que Oracle fue anterior a la estandarización de SQL), apostaría a que una gran parte de la renuencia a permitir identificadores más largos proviene de darse cuenta de que hay millones de DBA con millones de scripts personalizados que suponen que los identificadores tienen 30 caracteres de longitud. Permitir cada línea de código que va algo así como

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

romperse repentinamente porque el DBA hace 15 años usó VARCHAR2 (30) en lugar de DBA_TABLES.TABLE_NAME%TYPEen el script que causaría una revuelta masiva. Apostaría a que solo Oracle tiene miles de lugares donde este tipo de cosas se han realizado a lo largo de los años en varios paquetes y componentes. Reequipamiento todo ese código para apoyar identificadores más largos existentes sería un gran proyecto que es casi seguro que generará manera más costes en tiempo de desarrollo, control de calidad, el tiempo y los errores de reciente introducción de lo que generen beneficios.

Estaba buscando esto y encontré esta pregunta a través de Google, pero también descubrí que a partir de Oracle 12c Release 2 (12.2), este ya no es estrictamente el caso. ( https://oracle-base.com/articles/12c/long-identifiers-12cr2 )

En algún momento, cada DBA o desarrollador habrá alcanzado un punto en el que el límite de 30 caracteres para los nombres de objetos haya causado un problema. Este límite puede ser extremadamente doloroso cuando se realizan proyectos de migración de SQL Server o MySQL a Oracle. En Oracle Database 12cR2, la longitud máxima de la mayoría de los identificadores es ahora de 128 caracteres.

Esta es una nueva característica en 12.2, de acuerdo con ( http://blog.dbi-services.com/oracle-12cr2-long-identifiers/ ). Según esa publicación, 12.1 todavía estaba limitado a 30 caracteres.

Editar: Aquí hay un enlace a la documentación oficial de Oracle que explica el cambio. ( https://docs.oracle.com/cloud/latest/exadataexpress-cloud/CSDBF/longer-identifier-names.htm#CSDBF-GUID-F4CA155F-5A37-4705-8443-0A8C9E3F875C )

A partir de Oracle Database 12c Release 2 (12.2), la longitud máxima de los nombres de identificación para la mayoría de los tipos de objetos de base de datos se ha incrementado a 128 bytes.

Dada la necesidad práctica de los límites de longitud del identificador, un buen diseño restringe la longitud de los nombres reales para evitar tocar el techo cuando los nombres se combinan entre sí y con prefijos y sufijos.

Por ejemplo, una convención para nombrar restricciones de clave externa

FK_<table1>_<table2> 

limita los nombres de las tablas a 13 caracteres o menos; la mayoría de las bases de datos necesitarán más prefijos y sufijos, lo que limitará aún más la longitud de los nombres de las tablas.

Las infracciones de restricciones se informan en SQLERRM, que está limitado a 255 caracteres, y que la mayoría de los clientes utilizan para hacer visibles los errores. Sospecho que aumentar el tamaño permitido de los nombres de restricción afectaría significativamente la capacidad de informar sobre las violaciones (especialmente cuando una violación de restricción se ha propagado a través de algunas capas de código PL / SQL).

Creo que la longitud del identificador de 30 caracteres proviene de COBOL, que se estandarizó a fines de la década de 1950. Dado que los programas COBOL eran el usuario principal de SQL (y SEQUEL antes de eso (y QUEL antes de eso)), esto debe haber parecido un número razonable para la longitud del identificador.

Todas estas 'restricciones' quedan como respuesta a las limitaciones impuestas por las arquitecturas de procesador que provienen de los años 70. Desde entonces, los procesadores han evolucionado hasta el punto de que estas limitaciones ya no son necesarias; solo quedan. Sin embargo, cambiarlos es un GRAN trato para los escritores del RDBMS. Dado que estas limitaciones de longitud afectan a todo lo que se produce en el curso inferior, cambiarlo de manera involuntaria para decir que un nombre de procedimiento más largo puede y probablemente romperá muchas otras cosas, como informes de excepciones, el diccionario de datos, etc., etc. Requeriría una reescritura importante del Oracle RDBMS.

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.

Todos los comentarios anteriores son correctos, PERO debe tener en cuenta el costo de rendimiento de los nombres más largos. A principios de la década de 1990, cuando Informix instaló un gran cartel "Informix más rápido que Oracle". ¡en la ruta 101 al lado de la sede de Oracle, Informix permitió nombres de tabla de menos de 18 caracteres! La razón es obvia: los nombres de las tablas en su forma literal (es decir, como nombres reales en lugar de 't138577321' o algo así) se almacenan en el Diccionario de datos. Los nombres más largos equivalen a un Diccionario de datos más grande, y dado que el Diccionario de datos se lee cada vez que una consulta requiere un análisis riguroso, un diccionario de datos más grande equivale a un bajo rendimiento ...

ok, la limitación existe ...

¿pero realmente NECESITA más de 30 caracteres para nombrar una tabla / índice / columna?

al escribir consultas, con esa limitación TODAVÍA encuentro molestos algunos nombres de columna / tabla. Si el límite fuera mayor, podría encontrarme con tablas que requieren una consulta como:

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.

Pido disculpas por las enormes palabras: P