AcumatiCares
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 ERP que usaba GUIDs como todas sus claves, otro usaba sólo claves naturales mientras que un tercero usaba sólo enteros sustitutos. Cada uno, como veremos, tiene sus pros y sus contras. Acumatica utiliza múltiples esquemas para las claves de las tablas dependiendo de la necesidad y el contexto, lo que hace difícil elegir uno sobre otro, pero todos tienen su lugar en la base de datos. Pero empecemos con las claves más simples 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:
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 longitud variable. El GUID sustituto se utiliza ampliamente en muchas aplicaciones de bases de datos. Su fuerza reside en su universalidad y en la casi nula probabilidad de colisión. Son únicos no sólo en un sistema determinado, sino en todos los sistemas. Esto los hace ideales para el intercambio de datos o aplicaciones personalizadas entre sistemas. Tenga en cuenta que existen diversas variantes definidas por la norma RFC 4122, pero no las trataremos aquí. También existen otros GUID no conformes.
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:
¿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:
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 detrás de esto es que la tabla está usando el entero ID con todos sus pros mientras que el usuario ve el CD con todos sus pros. El truco detrás de la cortina aquí es que la tabla física utilizará el ID como su clave, pero el DAC (Data Access Class) utilizará el CD como su clave con el fin de ordenar las filas en la pantalla por CD en lugar de ID. Esto permite al usuario navegar de un CD a otro de forma natural mientras se mantiene la tabla con una clave entera. Además, todas las claves foráneas que hagan referencia a la tabla utilizarán el ID como clave 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 Negocio(Clientes, Proveedores, Sucursales, Empresas, Empleados) pero también las tablas más utilizadas(Elemento de Inventario, Almacenes, Cuentas GL, 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 ).
Ver la utilización de la acción CAMBIAR ID:
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 ).
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.
