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

pl sql add constraint (10)

Además del argumento de cagcowboy de que deriva del estándar SQL (históricamente, sospecho que la decisión de Oracle condujo al estándar SQL desde Oracle anterior a la estandarización de SQL), apostaría a que una gran parte de la reticencia a permitir identificadores más largos proviene de la constatación 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 sea algo así como

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

interrumpir repentinamente porque el DBA hace 15 años usó VARCHAR2 (30) en lugar de DBA_TABLES.TABLE_NAME%TYPE en el guión provocaría una revuelta masiva. Apostaría a que Oracle solo tiene miles de lugares donde este tipo de cosas se han hecho a lo largo de los años en varios paquetes y componentes. Volver a adaptar todo el código existente para admitir identificadores más largos sería un proyecto tremendo que casi seguramente generaría mucho más costos en tiempo de desarrollador, de control de calidad y errores recién introducidos que generaría beneficios.

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 nombres para los objetos, pero siempre hay un caso que aparece donde alcanzamos este límite, especialmente al nombrar claves externas.

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

Aparentemente, la respuesta es que romperá las secuencias de comandos actuales que no están protegidas. Digo que es algo muy preocupante, Oracle está tratando de ser la base de datos, seguramente este es el tipo de cosas que usted debe mejorar constantemente, de lo contrario su producto morirá la muerte de mil cortes.

Cada vez que veo este tipo de objeción en la empresa, creo que es hora de morder la bala y resolverlo. Si las personas ejecutan scripts que no verifican o mantienen cuando actualizan las versiones de Oracle, entonces que sufran las consecuencias de esa elección. Bríndeles una bandera de compatibilidad, aumente hasta 4000, luego guárdeme en el tiempo perdido cuando estoy creando objetos de tener que contar constantemente hasta 30 para verificar que el nombre sea "OK".

Creo que es el estándar ANSI.

EDITAR:

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

Parece que una versión posterior del estándar permite opcionalmente nombres de 128 caracteres, pero Oracle aún no lo admite (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)

Creo que la longitud del identificador de 30 caracteres proviene de COBOL, que fue estandarizada a fines de la década de 1950. Como 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.

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 golpear el techo cuando los nombres se combinan entre sí y con prefijos y sufijos.

Por ejemplo, una convención de 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.

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

En algún momento, cada DBA o desarrollador habrá llegado a un punto donde el límite de 30 caracteres para los nombres de los objetos ha 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 ahora es de 128 caracteres.

Esta es una nueva característica en 12.2, de acuerdo con ( http://blog.dbi-services.com/oracle-12cr2-long-identifiers/ ). De acuerdo con esa publicación, 12.1 aún 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 )

Comenzando con Oracle Database 12c Release 2 (12.2), la longitud máxima de los nombres de los identificadores para la mayoría de los tipos de objetos de base de datos se ha aumentado a 128 bytes.

La respuesta directa a la pregunta es que el estilo de Oracle se hereda de ideas más antiguas en las que 30 parecía mucho, y mucho más habría aumentado el riesgo de desanclar la memoria caché del diccionario de la memoria real en las bases de datos típicas.

Por el contrario, el espacio de nombre 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 construyendo automáticamente tablas de base de datos con nombres de columnas 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 de hoy en día.

No importa SQL92, es el cumplimiento con ODBC lo que realmente importa en 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 las comillas, el primero con un límite de 30 caracteres, el último una implementación completa de ODBC donde los identificadores largos raros son atendidos .

Incluso en el ámbito de las grandes bases de datos tradicionales, 30 caracteres a menudo es un problema donde los nombres deben seguir siendo significativos, consistentes y memorables. Una vez que comienzas a diseñar estructuras especializadas con herencia con nombre de función, comienzas a abreviar abreviaturas, y la consistencia pronto muere, porque, por ejemplo, el mismo identificador raíz representado como nombre de tabla o columna, en un caso necesitará una abreviatura adicional y en el otro no . Si se invita a los usuarios reales en números significativos a tales capas, las consecuencias son muy malas, y afortunadamente para cualquier base de datos obsoleta, la unidad principal ahora es separar al usuario de la base de datos a través de capas de objeto 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 les moleste. Elaborar esquemas de abreviatura sigue siendo un trabajo de por vida, parece.

Que Oracle no haya abordado esta vieja limitación tal vez se deba principalmente al hecho de que (aún) no está perdiendo mucho negocio frente a su competencia cuando no puede portar directamente diseños de bases de datos construidos utilizando identificadores más largos.

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 que los errores sean visibles. Sospecho que aumentar el tamaño permitido de los nombres de restricciones afectaría significativamente la capacidad de informar sobre las violaciones (especialmente cuando una violación de restricciones ha sido borrada a través de unas pocas capas de código PL / SQL).

Todas estas "restricciones" son respuestas a las limitaciones impuestas por las arquitecturas de los procesadores que provienen de los años 70. Desde ese momento los procesadores han evolucionado hasta el punto de que estas limitaciones ya no son necesarias; simplemente son sobrantes. Sin embargo, cambiarlos es un GRAN acuerdo para los escritores del RDBMS. Como estas limitaciones de longitud afectan a todo lo anterior, cambiarlo de cualquier manera para acomodarlo, digamos que un nombre de procedimiento más largo puede romper muchas otras cosas, como el informe de excepciones, el diccionario de datos, etc., etc., y así sucesivamente. Necesitaría una importante re-escritura de Oracle RDBMS.

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 montó una enorme valla publicitaria "Informix más rápido que Oracle". en la ruta 101 junto a la sede central de Oracle, Informix permitió nombres de tabla de solo 18 caracteres. La razón es obvia: los nombres de tabla 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 detallado, un diccionario de datos más grande equivale a un rendimiento deficiente ...

vale, la limitación existe ...

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

al escribir consultas, con esa limitación Sigo SENTANDO algunos nombres de columna / tabla molestos. Si el límite fuera más alto, podría encontrar tablas que requirieran 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.

Me disculpo por las enormes palabras: P