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

149

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'.

Chris Gill
fuente
3
¿Ya que debe haber un límite? Haga 64 caracteres y probablemente encontrará a alguien preguntando por qué no son 128, etc. ¿Cuánto dura un trozo de cuerda?
El presidente el
45
Es cierto, pero 30 es una cuerda muy corta. ¿Por qué no puede ser 4000, el tamaño de un Varchar2, a Oracle realmente le importa cuánto tiempo es una vez que ha analizado la consulta?
Chris Gill el
22
@TheChairman PostgreSQL me limita a 63 caracteres, y nunca he tenido un problema con ese límite de longitud. Es lo suficientemente grande como para que quepan mis nombres, y si estoy considerando un nombre más largo, es hora de comenzar a pensar en el impacto negativo en la legibilidad. Por otro lado, a menudo me encuentro con límites de longitud de nombre en Oracle y me veo obligado a reducir la legibilidad de mi nombre debido al límite de 30 caracteres. Algunas personas pueden quejarse del límite de 64, pero muchas personas ya tienen problemas debido al límite de 30 caracteres. Se trata de cumplir con el 99% de los casos de uso, y Oracle falla aquí.
jpmc26
1
¡Vamos, Oracle, te has convertido en un dinosaurio! Microsoft está haciendo un buen trabajo para hacer que el servidor SQL sea más amigable. Ahora relaja la restricción de longitud de nombre.
user3454439
1
Avance rápido a Oracle 12cR2, ahora es de 128 bytes en lugar de 30 :-) docs.oracle.com/en/database/oracle/oracle-database/12.2/newft/…
Stefan L

Respuestas:

71

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)

cagcowboy
fuente
1
Hmm, no es así como leo ese documento. Me dice que F391 es un elemento en la especificación de SQL / Foundation (lo que sea que sea eso), y que Oracle tiene soporte parcial para ello, con un límite de 30 caracteres.
skaffman
21
Cumplimiento parcial. Que broma. "Nuestros tornillos cumplen parcialmente los estándares métricos, excepto que no son métricos".
Jens Schauder
55
No he leído la especificación F391 en detalle, pero supongo (tal vez incorrectamente) que "identificadores largos" significa un aumento en la longitud del identificador de 30 a 128. Por lo tanto, decir que admite "parcialmente" esto al permitir 30 caracteres es Un poco descarado. No es compatible con el nuevo estándar, aún es compatible con el antiguo estándar (aunque el 25% del camino hacia el nuevo estándar) ¿¡¿Eso tiene sentido? !!?
cagcowboy
77
El estándar SQL-92 está aquí contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt , pero si lee la sección "17.1 Descripción de las áreas de descriptor de elementos SQL", dice que los identificadores como nombres y esquemas deben permitir al menos 128 caracteres.
Rick
46
El hecho de que los fanáticos de Oracle no vean la utilidad de más de 30 identificadores de caracteres es inquietante. "Haga que sus nombres sean significativos / descriptivos, utilice guiones bajos en lugar de mayúsculas y quédese con menos de 30 caracteres". Eso nunca superaría los 30 caracteres. Amirita? Más bien abrevia tus abreviaturas y cuando ninguno de los nombres tiene sentido, pasa todo el día leyendo / actualizando la documentación.
Adam Jones
45

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.

Justin Cave
fuente
13
+1 Es casi seguro que es uno de los muchos problemas de diseño heredados de Oracle.
skaffman
43
Seguramente es hora de hacer crecer un par y aumentarlo: agregue una bandera para que los DBA puedan refinarlo nuevamente a 30. Los problemas heredados como este siempre deben confrontarse y clasificarse; de ​​lo contrario, terminará paralizando todo el código base, y la gente simplemente se moverá a otra cosa
Chris Gill
66
No solo millones de líneas de código escrito de DBA, sino también un montón de código interno de Oracle. Este tema surgió en una sesión con Steven Feuerstein y dijo que no creía que alguna vez lo cambiarían.
Matthew Watson el
10
Tampoco podían anunciarlo como una nueva característica ... pasarían mucho tiempo extendiendo el límite y luego anunciarían "¡ahora puede usar nombres de más de 30 caracteres!". Serían el hazmerreír.
skaffman
9
Si todavía usa scripts de 15 años, algo está extremadamente mal . Además, arreglarlos sería un costo único (posiblemente con algo más para el mantenimiento continuo), mientras que los desarrolladores continuarán perdiendo el tiempo creando innecesariamente nombres abreviados horriblemente indefinidamente. @skaffman Ya son un hazmerreír por no arreglarlo (y una gran cantidad de otras decisiones de diseño que son patéticas en la era moderna, como ningún tipo booleano o de autoincremento), en lo que a mí respecta.
jpmc26
11

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.

Kanmuri
fuente
128 bytes / 4 bytes (Unicode) = 32 caracteres. Al menos, entiendo que 4 bytes para caracteres no Unicode no es tan poco común. Tengo que preguntarme si eso simplemente significa que ahora están apoyando a Unicode. Al igual VARCHAR2(2)que no significa 2 caracteres sino 2 bytes.
Seth
1
Veo su punto, pero los caracteres vs bytes dependen de su conjunto de caracteres de la base de datos. Esa configuración determina la codificación de los tipos de datos char (como varchar2), así como la codificación de los identificadores db. Esto contrasta con el conjunto de caracteres nacionales, que se utiliza para los tipos de datos nchar. Entonces, sí, si tiene una codificación tal que sus identificadores están usando 4 bytes por carácter (suponiendo que se pueda usar como el conjunto de caracteres DB), ahora tendría 32 en lugar de 7. Pero creo que para la mayoría de los casos de uso, los identificadores serían caracteres de un solo byte.
Kanmuri
6

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.

Lorenzo Gatti
fuente
5

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).

Gary Myers
fuente
Entonces, ¿ampliar esa mesa, entonces?
skaffman
2
No es una tabla, sino cómo el software del cliente realmente obtiene errores de la base de datos.
Gary Myers
@skaffman La longitud de SQLERRM es una especificación API / ABI. Cambiar esto significaría tener que parchear todos los controladores OCI del planeta (de lo contrario, desbordamiento del búfer). Podrían transferir el cambio al cliente para aumentar el buflen en OCI 13 primero y el servidor en algo como Oracle 15, donde los clientes de OCI 10 ya no serían compatibles, supongo. (Tal vez incluso lo estén considerando ahora, pero la versión principal de Oracle se lanza solo cada pocos años; y luego aún podemos encontrar problemas de actualización de script / aplicación cuando las aplicaciones se migran a un servidor / cliente diferente)
cowbert
4

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.

Michael Dillon
fuente
55
Creo que la primera versión de Oracle fue escrita en Fortran, que creo que tiene un límite de longitud de identificador de 31. Quizás sea relevante.
David Aldridge
4

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.

Mac
fuente
2

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.

atconsul
fuente
No a Oracle. ODBC es un bebé de Microsoft, no uno de Java. Sigue siendo una biblioteca auxiliar separada vinculada a OCI (mire cómo se implementa instantclient; para que ODBC funcione con instantclient, necesita tanto el controlador OCI como las cremalleras de ODBC instantclient). La plataforma de cliente principal de Oracle (además de Legacy Pro * C / C / C ++) es JDBC, que está directamente vinculada a OCI, no a ODBC.
cowbert
1

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 ...

Rafael
fuente
77
No hay absolutamente ninguna razón para que la coincidencia exacta de cadenas cortas sea un cuello de botella en cualquier software moderno a menos que lo esté haciendo miles de millones de veces, lo cual no es el caso en el análisis de consultas. Las consideraciones de tamaño y rendimiento pueden haber sido importantes cuando esta parte de Oracle se diseñó por primera vez, pero actualmente no son realmente relevantes.
Sarah G
-7

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

usuario173422
fuente
29
Sería bueno poder nombrar claves externas con los nombres de las tablas y columnas a las que se unen, por lo tanto, cuando se produce una excepción de clave externa, no tiene que buscar las columnas que causaron la falla. Por otra parte, Oracle podría decirle esa información ...
Chris Gill
10
Hay muchas razones por las que necesitamos más de 30 caracteres, aunque generalmente 30 caracteres son suficientes. En algún momento, el nombre de una tabla debe ser lo suficientemente detallado como para ser significativo. Por ejemplo, tengo esta tabla llamada sch_PatternRunTimeException, tiene exactamente 30 caracteres de longitud. Ahora, necesito agregar una tabla de reflejo llamada sch_DevPatternRunTimeException. Este estándar de nomenclatura adicional de 3 caracteres no funciona para Oracle, MSSQL no tiene ningún problema. Esto me está obligando a encontrar un nuevo nombre. Cambiar el nombre de la tabla es factible, pero afectará las operaciones de nuestros clientes, lo que tratamos de evitar.
dsum
66
Si en el 99.9% de los casos posibles, +30 caracteres son molestos , no significa que serían útiles el otro 0.1%.
René Nyffenegger
14
Ahhh el argumento de la pendiente resbaladiza. Un límite de solo 4 caracteres alfanuméricos nos daría más de 1 millón de combinaciones de tablas, por lo que nadie realmente "necesita" más de 4. Sin embargo, aquí estamos. Y en realidad no son 30 caracteres, son menos de 30 caracteres ya que mi convención de nomenclatura de mayúsculas y minúsculas tiene que ser eliminada por la falta de mayúsculas y minúsculas y reemplazada por nombres delimitados con guiones bajos. Combina eso con varios prefijos / sufijos y tienes la suerte de tener incluso 20 caracteres. ¿Quién no preferiría que un nombre de índice robusto se hiciera eco de un error de violación sobre una mezcolanza de abreviaturas y guiones bajos?
b_levitt
Acordó que esto no está abordando el problema. Normalmente los seres humanos no necesitan nombres de columna más largos, pero hay muchos casos en los que los nombres de objetos se generan automáticamente.
fool4jesus