¿Hay alguna razón para usar nombres de tabla extremadamente abreviados?

Estamos utilizando una configuración de base de datos de la aplicación de un proveedor que tiene nombres de tablas de bases de datos terriblemente difíciles de leer, y no hay documentación sobre qué se almacena dónde. Puedo ver por qué uno puede querer ofuscar la estructura de su tabla en una aplicación propietaria, pero uno de los puntos de venta de esta aplicación (Enterprise Resource Planning) fue su personalización.

Los nombres de las tablas son como aptrx (Transacciones de cuentas por pagar) y apmaster_all (curiosamente, esta es la tabla de proveedores). Es una base de datos extremadamente compleja, así que me preguntaba si había alguna lógica en la convención o si simplemente se estaba ofuscando intencionalmente o no.

Que yo sepa, la longitud del nombre de la tabla no afectará notablemente el rendimiento, ¿correcto? La base de datos es muy compleja (cientos de tablas), por lo que la ordenación tiene sentido, pero no puedo imaginar por qué CuentasPayableTransactions no es preferible a aptrx ...

Oracle ha tenido un límite de larga data en los nombres de tablas de 30 caracteres. Sospecho que este es un problema heredado basado en un entorno original de 16 bits.
La longitud del nombre de una tabla podría tener un efecto minúsculo en el rendimiento, ya que todos los nombres deben almacenarse en un diccionario de datos y analizarse para consultas, pero no creo que pueda medir el impacto.

Un efecto más importante de los nombres cortos de tablas es que es difícil trabajar con ellos. Yo también tengo que mantener un esquema de base de datos empresarial con nombres cortos. No hay una buena razón para tener nombres de tabla cortos. La facilidad de mantenimiento siempre supera la ofuscación o los viejos hábitos de DOS.

Siento que hay dos cosas que aún deben decirse o elaborarse:

1. Nombrar cosas no es tan trivial como parece

   Solo hay dos problemas difíciles en Informática: invalidación de caché y nombrar cosas. Phil Karlton

2. Mientras que los nombres cortos sin sentido siempre son malos, los nombres largos no siempre son buenos: nuestros cerebros tienen un umbral tl; dr incorporado que es sorprendentemente bajo. 30 caracteres es normalmente suficiente, pero yo prefiero los RDBMS para permitir más por los excepcionales casos en que no lo es (y al igual que en el lenguaje, los nombres más largos son más útiles para cosas que no hablan tan a menudo - como nombres de restricción, y los nombres más cortos son más útiles para las tablas que consultamos todo el tiempo)

Siempre tengo la tentación de pasar muy poco tiempo eligiendo nombres, y siempre lo lamento más tarde si lo hago; el cambio de nombres ocurre raramente

Pereza. Las opciones de IntelliSense y de terceros hacen que escribir sea una excusa realmente difícil de justificar. Prefiero que los nombres tengan palabras significativas y legibles.

Los nombres de las tablas son como aptrx (Transacciones de cuentas por pagar) y apmaster_all (curiosamente, esta es la tabla de proveedores). Es una base de datos extremadamente compleja, así que me preguntaba si había alguna lógica en la convención o si simplemente se estaba ofuscando intencionalmente o no.

Las abreviaturas conocidas suelen ser preferibles a deletrear las cosas. Cuando algunas personas conocen bien una abreviatura, pero no lo suficiente, dejamos de llamarla abreviatura y comenzamos a llamarla código.

Las abreviaturas conservan espacio en plataformas que tienen límites estrictos, aunque esto es menos importante ahora que hace 30 años. (Parece recordar haber trabajado en un sistema en la década de 1980 que lo limitaba a 6 u 8 caracteres para un nombre de tabla).

Las abreviaturas generalmente hacen que los nombres de tablas y columnas sean más fáciles de leer, siempre que la abreviatura se haga bien. Si trabajé en código para AP todo el día, prefiero leer nombres de columna como "ap_trx.inv_num" que "accounts_payable_transactions.invoice_number". (Me gustan los guiones bajos). Escribir nombres largos no es un gran problema con un buen editor de texto.

En los sistemas de contabilidad, tanto "ap" como "trx" son abreviaturas bien conocidas. Otros incluyen "ar", "gl" y "gj", para cuentas por cobrar, libro mayor y diario general.

En un sistema bien diseñado, si encuentro transacciones de cuentas por pagar en una tabla llamada "aptrx", espero encontrar transacciones de cuentas por cobrar en artrx, transacciones de contabilidad general en gltrx, etc. Encuentro "apmaster_all" un poco desconcertante, pero si también encuentro "armaster_all", supongo que el primero tenía a todos los vendedores (a diferencia de los vendedores activos o inactivos), y que el segundo tenía de manera similar a todos los clientes.

En otros dominios problemáticos, encontrará otras abreviaturas bien conocidas. En el direccionamiento, encontrará abreviaturas como "addr" para la dirección, "st" para la calle, "usps" para el Servicio Postal de los Estados Unidos, "ups" para el United Parcel Service, "cty" para el condado, "zip" para el Mejoramiento de Zona Código, y así sucesivamente.

No llamaría a esto ofuscación. Si las transacciones de cuentas por pagar se almacenaran en una tabla llamada "cdrs21", llamaría a eso ofuscación. (Aunque una vez trabajé para una empresa que nombró todos sus módulos ensambladores de mainframe de esa manera. Límites de caracteres, no ofuscación).

Pero las bases de datos útiles crecen y te encuentras con un problema cuando las bases de datos se hacen grandes. A medida que agrega dominios problemáticos a su base de datos, se encuentra con situaciones en las que las abreviaturas conocidas chocan. Si trata con los medios de comunicación, "ap" también podría abreviar "Associated Press", "prensa alternativa" o "colocación avanzada". Cuando eso sucede, es hora de abandonar las abreviaturas o cambiar a códigos. Cuanto más grande es la organización (y más grande es la base de datos), más frecuentemente encuentro códigos.

Simplemente hablando con "Dios mío, las gafas no hacen nada por esta horrible convención de nomenclatura". El equipo de administración de datos en mi último entorno declaró que la razón para usar nombres de tabla abreviados era una limitación de DB2 (teníamos DB2 en z / os y SQL Server) de 18 caracteres para tablas y columnas. Puntualmente señalé que esto era incorrecto con la documentación del sitio de IBM. Luego declararon que era un problema de COBOL (sí, se desarrollaron activamente COBOL) en caso de que fuera necesario hablar con la base de datos que luego fue desestimada por los jinetes de MF. Finalmente, su respuesta fue que es nuestro estándar de publicación.

Solicitamos al comité de normas que aumente la longitud de 18 a 32 caracteres y recibimos una limitación de 30 caracteres. Como resultado, las tablas pasaron de nombres inútiles de 'SR_M_DLY_ADV_PRD_S' a 'IDX_FDSHRCLAS_LIF_RTRN_STATS_X' FML

Entonces, en mi docena de años de experiencia, los nombres de tablas acortados no brindan beneficios tangibles y resultan en un mayor costo de desarrollo y mantenimiento, ya que siempre debo consultar los diccionarios de datos para traducir la basura en la pantalla a un identificador significativo. Lo que puede contrastarse con entidades con nombres lógicos con las que he trabajado y puede recrearse principalmente de la memoria porque fueron nombradas intuitivamente.

Es un hábito (estoy de acuerdo con Kevinsky). Fue una reacción a algunos problemas antiguos (tal vez existentes) a la restricción (longitud del nombre, espacio entre palabras de nombres complejos, multilingüe, etc.) del sistema operativo (DOS, Windows, por ejemplo) y algún software que no manejaba esos nombres. Las personas experimentadas dijeron: "Hazlo (usa nombres cortos y separados con subrayado) y todo estaría bien".

Me gusta usar nombres descriptivos por los motivos antes mencionados en los carteles.

Pero también hay otro beneficio. Por ejemplo, con nombres descriptivos, le permite usar nombres anidados. Digamos que tiene una mesa llamada Empleado. Si tiene una relación con otra tabla, podría llamarse EmployeeAddress. O departamento de empleados. Con los nombres crípticos y abrigados esto es casi imposible.

Depende de cuán complejas sean las definiciones subyacentes de cada columna. Creo que las personas se vuelven perezosas con la gestión de metadatos cuando ven este tipo de nombres de columna muy descriptivos, e incluso son descripciones incompletas. También podrías preguntar por qué abreviar algo.