Donde la clave son las llaves del reino

Entender las claves de la base de datos y cómo se utilizan mejor en Acumatica es una habilidad importante y fundamental para el desarrollador. Ya sea diseñando nuevas pantallas o módulos en Acumatica, la decisión sobre qué esquema de claves utilizar no sólo influirá en la forma de codificar, sino que también influirá en la facilidad con la que se utilizarán sus aplicaciones.
Stéphane Bélanger | 20 de diciembre de 2023

Donde la clave son las llaves del reino

Revisado: Dic, 2023

Introducción

En una aplicación de base de datos, las claves de tabla desempeñan un papel importante. Además, cuando diseñas nuevas pantallas o incluso un módulo, la decisión sobre qué esquema de claves utilizar no sólo influirá en cómo codificas tus DAC, sino que también influirá hasta cierto punto en lo fácil que será utilizar e integrar tu aplicación. En los primeros días de trabajo con Acumatica, solía rascarme mucho la cabeza a la hora de tomar decisiones al elegir mis claves o cómo utilizar un ID frente a un CD en Consultas genéricas.

Por qué debería importarte

Decidir cambiar la clave primaria de una de las tablas es muy difícil una vez que has instalado la aplicación en otros sitios, lo que normalmente significa que tendrás que vivir con tu elección durante mucho tiempo, si no para siempre. Antes de seguir adelante, definamos lo que entendemos por claves[1].

Clave primaria (PK): Columna o grupo de columnas de una tabla que identifica de forma unívoca cada fila de esa tabla. Las claves primarias no pueden estar duplicadas, es decir, el mismo valor no puede aparecer más de una vez en la tabla. Una tabla no puede tener más de una clave primaria.

Clave candidata: También es una clave única para identificar un registro de forma única en una tabla, pero una tabla puede tener varias claves candidatas. Ejemplos de claves candidatas típicas son correos electrónicos, nombre de la empresa, ID de empleado,número DUNS[2].

Clave alternativa: Columna o grupo de columnas de una tabla que identifica de forma única cada fila de una tabla concreta. Una tabla puede tener múltiples opciones para una clave primaria, pero sólo una puede establecerse como clave primaria. Todas las claves que no son la clave primaria se denominan claves alternativas.

Clave natural: Columna o grupo de columnas de una tabla que identifica unívocamente cada fila de esa tabla de forma humanamente reconocible. Un código o un número de documento suele denominarse clave natural.

Clave sustituta: Una clave artificial que pretende identificar de forma única cada registro se denomina clave sustituta. Este tipo de clave se utiliza cuando no se tiene o no se quiere utilizar una clave natural como clave primaria.

Clave foránea (FK): Columna o grupo de columnas de una tabla que es la clave primaria de otra tabla.

Diferencia entre clave e índice

Como ya se ha dicho, una clave es una columna o un grupo de columnas o, si se quiere, un grupo de valores. Un índice, por otro lado, ayuda a las bases de datos a localizar el lugar físico donde se almacena la fila basándose en los valores proporcionados por la clave. Por tanto, el índice es como un diccionario de claves y ubicaciones. La base de datos utiliza el índice para encontrar rápidamente la fila relacionada con los valores de la clave.

Qué esquema utilizar

Algunas aplicaciones de bases de datos suelen utilizar un único esquema (tipo) para identificar las claves. En el pasado, trabajé con un sistema ERP que utilizaba GUID como todas sus claves, otro que solo utilizaba claves naturales y un tercero que solo utilizaba enteros sustitutos. Cada uno de ellos, como veremos, tiene sus ventajas y sus inconvenientes. 

Acumatica utiliza varios esquemas para las claves de las tablas en función de las necesidades y el contexto, lo que dificulta elegir uno en lugar de otro, pero todos ellos tienen su lugar en la base de datos. Pero empecemos por las claves más sencillas y vayamos avanzando hacia las más complejas.

La llave natural

Una clave natural es un valor simple (como una cadena) que identifica claramente el significado de la fila. Si digo, por ejemplo, "US", "CA" o "MX", sabrás al instante de qué países estoy hablando. Si digo "H0H 0H0[3]" o "90210[4]", probablemente también los conozcas, aunque esto es un poco más difícil. Por último, si digo "NONTAXABLE", no tengo que explicarlo. Aunque hoy en día es raro que algo sea no imponible, per se.

Ventajas: Altamente reconocible, más fácil de entender, más corto que otros, da contexto de uso, más fácil de usar en consultas a bases de datos.

Contras: El tamaño (normalmente fijo) debe decidirse con antelación para que no puedan crecer más fácilmente. Los tamaños pequeños llevan a que sean códigos irreconocibles. Una vez guardada la clave, no se puede cambiar sin dificultad.

La clave entera sustitutiva

El número entero sustituto es una de las claves más utilizadas en las aplicaciones de bases de datos. Ocupan muy poco espacio (normalmente 32 bits), pueden incrementarse automáticamente y el número de filas puede ser bastante considerable (alrededor de 2.000 a 4.000 millones dependiendo de si tienen signo o no). Una clave de este tipo será visible o no en función de su uso.

Ventajas: Almacenamiento y acceso a la base de datos eficientes, la mayoría de las tablas tienen un número reducido de filas, las claves significativas son más fáciles de leer y utilizar en las consultas, autoincrementable, modelo sencillo y del agrado de la mayoría de los desarrolladores.

Contras: Sus valores no son fáciles de reconocer, normalmente se requiere una tabla unida para entender el significado. Una vez guardada la clave, no se puede cambiar fácilmente, si es que se puede.

Adecuado para:

  • Tablas con muchas filas
  • Tabla de tratamiento de filas
  • Secuencias de filas ordenadas

Algunos ejemplos:

PXDBIdentity

PXDBLongIdentity

ChildTableKey

LineNbr

La clave GUID sustituta

Un identificador único universal (UUID) o identificador único global(GUID) es un valor de 128 bits (16 bytes) que normalmente se divide en cinco grupos de longitudes variables. El GUID sustituto se utiliza ampliamente en muchas aplicaciones de bases de datos. Su ventaja radica en su universalidad y en que la probabilidad de que se produzca una colisión es prácticamente nula.

Son únicos no solo en un sistema concreto, sino en todos los sistemas. Esto los hace ideales para intercambiar datos o aplicaciones personalizadas entre sistemas. Tenga en cuenta que el estándar RFC 4122 define varias variantes, pero no las trataremos aquí. También existen otros GUID que no se ajustan a la norma.

Ventajas: Universales y únicos debido a su naturaleza. Están bien documentados y estandarizados. Su naturaleza irreconocible los convierte en un buen candidato para las referencias "secretas". Dado un GUID, es prácticamente imposible adivinar un valor futuro, aunque algunas variantes son más débiles en este aspecto.

Contras: Son difíciles de escribir e imposibles de recordar. Por lo tanto, debes utilizar una sentencia join o una acción de copiar y pegar para utilizarlos en consultas a bases de datos. Su valor es prácticamente irreconocible, por lo que no dan contexto de sus usos específicos.

Algunos ejemplos:

WebHookID

FilterID

¿Qué ocurre con las claves de Acumatica?

Acumatica ha hecho un gran trabajo al elegir sus claves aunque a primera vista no lo parezca.

La llave natural

Muchas tablas de Acumatica utilizan una clave natural cuando es apropiado.

Algunos ejemplos:

CustomerClassID

Tipo de documento

Adecuado para:

  • Nombres de código (TaxZoneID, TermsID, CountryID, StateID, etc.)
  • Nombres de clases (ItemClassID, CustomerClassID, etc.)
  • Documentos (SOOrder.OrderType, SOOrder.OrderNbr, GLDocBatch.Module, GLDocBatch.BatchNbr, etc.)

 

 

 

 

La clave entera sustitutiva mejorada

Cuando empecé con Acumatica, este esquema de claves me resultaba bastante intrigante hasta que comprendí realmente el poder que hay detrás de él. Este esquema de claves se compone de 2 partes:

  • La clave sustituta real, también conocida como ID, que es la clave física real de la tabla (en la mayoría de los casos, un número entero de 32 bits, pero a veces un número entero de 64 bits).
  • La clave natural visible, también conocida como CD, es la clave visible para el usuario.

La idea es que la tabla utilice el identificador entero con todas sus ventajas, mientras que el usuario vea el CD con todas sus ventajas. El truco que hay detrás es que la tabla física utilizará el identificador como clave, pero la DAC (Clase de Acceso a Datos) utilizará el CD como clave para ordenar las filas en pantalla por CD en lugar de por identificador. 

Esto permite al usuario navegar de un CD a otro de forma natural, al tiempo que se mantiene la tabla con una clave entera. Además, todas las claves externas que hagan referencia a la tabla utilizarán el ID como clave externa física, pero volverán a mostrar el CD al usuario. 

Este esquema se utiliza para las tablas más importantes, como todas las cuentas de la empresa (clientes, proveedores, sucursales, sociedades, empleados), pero también para las tablas más utilizadas (artículos de inventario, almacenes, cuentas del libro mayor, subcuentas, proyectos, tareas, activos, rutas, etc.).

La otra buena característica de este esquema es que el usuario también puede cambiar el CD relacionado con el ID utilizando una acción global llamada CAMBIAR ID. Utilizando esa acción, el usuario puede "recodificar" claves a medida que avanzan el negocio y la implementación.

Adecuado para:

  • Cuentas de empresa (sobre todo porque es posible que quiera cambiar la clave más adelante)
  • Clave cambiable de las tablas más utilizadas

En los 2 GIST siguientes, observe cómo la clave física de la tabla (véase[BAccount_PK] en la tabla BAccount) es diferente de la clave DAC (véase IsKey = true en el campo AcctCD ).

BAccountID vs AcctCD

Tabla BAccount

Ver la utilización de la acción CAMBIAR ID:

Donde la clave son las llaves del reino

La clave GUID sustituta mejorada

Muy similar a su homólogo de enteros, este esquema de claves consta de 2 partes:

  • La clave sustituta real, también conocida como ID, es la clave GUID física real de la tabla.
  • La clave natural visible, normalmente un nombre de cadena, es la clave visible para el usuario.

Adecuado para:

  • Referencias a objetos del sistema
  • Identificadores globales de valores compartidos

En los 2 GIST siguientes, observe cómo la clave física de la tabla (véase el[WebHook_PK] en WebHook Table) es diferente de la clave DAC (véase IsKey = true en el campo Name ).

WebHookID vs Nombre

Tabla WebHook

Contrariamente al típico ID/CD, las pantallas que utilizan este esquema no tienen una acción global para CAMBIAR ID aunque podría crearse una fácilmente.

La clave detallada

Una clave de detalle es una clave utilizada para una tabla que representa a los hijos de otra tabla. Normalmente, se toma la tabla resumen (el padre) y se le añade otro campo clave. De nuevo, existen múltiples patrones, y veremos cuál es el preferido.

El simple

Un diseño sencillo para ese tipo de clave de detalle es tomar la clave Resumen y añadir el valor de la clave primaria candidata para el detalle. Este diseño (bastante raro) sólo se debería favorecer si se quiere simplificar la unicidad de la clave pero sin tener las ventajas del siguiente diseño.

Ejemplos : GITable, DetalleCuenta, Estado

Lo bueno

Un buen diseño para las claves de detalle es tomar la clave Resumen y agregarle un LineNbr. Acumatica favorece esto en la mayoría de los casos por múltiples razones:

  • Es fácil: un simple número entero y voilà
  • Está automatizado: utilizando el LineNbrAttribute, puede generar automáticamente el LineNbr.
  • Es ordenable y arrastrable: si tu DAC implementa ISortable Y utilizas un PXOrderedSelect
  • Permite "duplicados" al considerar la clave primaria candidata que suele encontrarse en la fila de detalle(InventoryID por ejemplo)
  • Permite valores nulos para las claves candidatas, lo que normalmente haría que la clave fuera única.

Ejemplos: SOLine, POLine, ContractDetail, ARTran, APTran, GLTran, etc.

Compartidos

Otra opción de diseño interesante para una tabla Detalle es no utilizar la clave de resumen en absoluto y crear una clave hecha con un Entero Sustituto y añadir el NoteID del Resumen como "padre". Este diseño permite que la tabla de detalle (como CRRelation) sea compartida por otras múltiples tablas de resumen (como CRLead, CRCase, CROpportunity, CRContact, BAccount, etc.). Sin embargo, esto suele requerir una versión especial de PXSelect (como CRRelationsList) para manejar la relación con el padre.

Ejemplo: CRRelation

Conclusión

Espero haber ayudado un poco a desvelar el misterio que se esconde tras la elección de teclas en Acumatica. Lo que es importante recordar es que "Una talla para todos" no se aplica a Acumatica. Usar una clave natural, aunque es el esquema más fácil de usar, no es la mejor opción para todos los contextos.

Con el tiempo, me he dado cuenta de que si entiendes las claves de una aplicación, entenderás muchas cosas con un solo vistazo.

Felices consultas a todos.

____________________________

Notas a pie de página

[1] Dado que Acumatica es una aplicación multi-tenant, sus claves de tabla casi siempre incluyen un campo CompanyID. Ignoraremos este hecho en aras de la simplicidad.

[2 ] Data Universal Numbering System, abreviado como DUNS o D-U-N-S, es un sistema patentado desarrollado y gestionado por Dun & Bradstreet que asigna un identificador numérico único, denominado "número DUNS", a una única entidad empresarial.

[3] Código postal de Santa Claus (en Canadá, obviamente).

[4 ] Una famosa serie de televisión estadounidense para gente mayor como yo.

Autor del blog

La carrera de Stéphane, que abarca más de 25 años, comenzó como desarrollador de ERP en un lenguaje 4GL llamado Miracle. Al cabo de unos años, le enviaron a Filadelfia para trabajar con Weyerhaeuser con un contrato de 10 días que duró 4 años, donde ayudó a rediseñar los módulos de Transporte y EDI. Creó, entre otras, casi una docena de nuevas transacciones EDI. A continuación, se adentró en el desierto de las personalizaciones y el middleware Java en busca de su ERP Graal. En 2016, fue contratado por el estudio de videojuegos Behaviour Interactive, donde seleccionó, implementó e integró un ERP con otras aplicaciones en la nube. ¿Qué ERP? Acumatica por supuesto. En 2018, decidió volver a sus raíces como desarrollador de ERP y empezó a trabajar para partners Gold de Acumatica de primer nivel para compartir sus conocimientos, su pasión y sus ideas. Ha sido feliz desde entonces.

Reciba las actualizaciones del blog en su bandeja de entrada.