Recomendaciones para la elección de primary key

Recomendaciones para la elección de primary key

Es un hecho notorio, que en el campo de desarrollo de sitios web no triviales o de desarrollo de cualquier aplicación, se requieren bases de datos, y puesto que las habilidades para el diseño y creación de base de datos son diferentes a las habilidades de codificación, es de vital importancia para cualquier programador dominar con destreza y a profundidad, los principios y prácticas para el diseño y uso de base de datos.

Tipos de Tablas Básicas

En la siguiente tabla se listan los patrones que describen los distintos tipos de opciones de tablas para almacenar requisitos de negocio. Cada patrón se caracteriza por el número relativo de columnas y filas, así como también la naturaleza de la data a almacenar, ya sean registro de datos permanentes o interacciones entre datos permanentes.

Nombre del Patrón cantidad relativa de columnas cantidad relativa registros Tipo Notas
Referencia pequeña Pequeña permanente Usa primary key de una sola columna tipo carácter.
Maestra pequeña pequeña pequeña permanente Usa primary key de una sola columna tipo carácter.
Maestra grande Grande Grande Permanente Usa primary key integer auto-generada.
Transacciones n / a n / a transitorios Describen las interacciones entre las tablas, como una compra de un producto por un cliente, o la inscripción de un estudiante en una clase. Usa primary key integer auto-generada.
Referencia cruzada n / a n / a permanente Describe las relaciones entre tablas maestras. Usa primary  key multi- columnas.

Cómo elegir una Primary Key

Un buen diseño de base de datos comienza con elección de una correcta primary key

La elección de una primary key (claves primaria) es uno de los pasos más importantes en el diseño de una buena base de datos. Una primary key es una columna de tabla que sirve a un propósito especial. Cada tabla necesita una primary key porque garantiza la accesibilidad a nivel de fila (registro). Si usted elige una apropiada primary key, entonces puede especificar el valor de la clave que le permitirá consultar cada fila de tabla individualmente y modificar cada fila sin alterar otras filas de la misma tabla. Los valores que componen la columna de primary key son únicos; no hay dos valores iguales.

Cada tabla tiene una única primary key, la cual puede estar conformada por una o varias columnas. Una clave primaria concatenada está conformada por dos o más columnas. Sin embargo, en una simple tabla, también se puede encontrar varias columnas o grupos de columnas que podrían servir como primary key, estas columnas son usualmente llamadas candidate keys (claves candidatas). Una tabla puede tener más de una clave candidata, pero sólo una candidate key puede convertirse en la primary key para esa tabla.

Hay varios modelos que compiten entre sí sobre cómo elegir las primary key. La mayoría de ellos recomiendan utilizar un solo tipo de primary key para todas las tablas, por lo general un integer (número entero). Por otra parte, en contraste con estos modelos, se pueden encontrar aplicaciones robustas que utilizan diferentes tipos de primary key para diferentes tipos de tablas.

En los últimos 20 años he trabajado en proyectos grandes y pequeños, tanto simples como complejos. A veces tuve el control total de la técnica de diseño, en otras ocasiones tenía que trabajar con las técnicas que otros me dieron, y a veces era un poco de ambas.

En este post, voy a resumir la forma como he venido trabajado las técnicas de diseño de tablas en esos años, y cómo lo hago actualmente.

En conclusión, el objetivo de esta guía es dar a conocer un conjunto de técnicas que realmente funcionen, y no sólo promover simplemente un modelo particular que establezca la forma de cómo lo deberían hacer todos.

Podemos adoptar estos tópicos como “reglas de oro”. Una regla de oro, es una idea guía que tenderá a ser manejable y aplicable la mayor parte del tiempo, pero que puede cambiar bajo ciertas circunstancias.

Regla de Oro 1: Utilizar Primary Key tipo Character para TABLAS REFERENCIAS

Una tabla de referencia es aquella que tiende a ser muy constante en el tiempo y relativamente tiene pocas columnas. A menudo, una tabla de referencia puede estar ya poblada por el programador. Para ilustrar este tipo de tablas, podemos citar los siguientes ejemplos: las tablas de códigos de país (tal vez con prefijos telefónicos internacionales), una tabla de provincias o estados dentro de un país, o una tabla de zonas horarias. A continuación, veremos el ejemplo de una Aplicación de Gestión de Escuela, en el cual el usuario tiene una tabla de referencia de las asignaturas, tales como DATABASE, SISTEMAS, ALGORITMOS, entre otras.

Para este tipo de tablas lo más recomendable es hacer la Primary Key  de tipo Character, que a menudo es conocida como tipo “código”, tal como “código de zona horaria” o “código de país” o “código de objeto”. La estrategia es hacer un código que que represente un valor con significado que la gente puede entender y que pueda utilizar de manera intuitiva. Esto permite que nuestras tablas sean más fáciles de usar, tanto para el programador como para el usuario final.

Volvamos al ejemplo de nuestra Aplicación de Gestión de Escuela. En este sistema tenemos una tabla de profesores (poblada por el personal de la escuela) y una tabla de asignaturas, que hemos implementado como una tabla de referencia. Cuando un profesor se registra en la escuela, alguien tiene que introducir las asignaturas que ese profesor está calificado para enseñar.  En la siguiente figura se pueden observar dos representaciones de cómo se pueden implementar estas tabla. ¿Cual es más fácil de leer?

TABLA PROFESORES_X_ ASIGNATURAS, TIPO REFERENCIA CRUZADA

EJEMPLO 1: CLAVE ENTERA EJEMPLO 2: CLAVE CARACTER

PROFESOR| ASIGNATURA   PROFESOR | ASIGNATURA
— + —                                            ———+ ———–
72 | 28                             ASILVA       | DATABASE
72 | 32                             ASILVA       | ALGORITMOS

72 | 72                             ASILVA       | REDES
45 | 28                           WRANGEL   | SISTEMAS
45 | 29                           WRANGEL   | BIGDATA
45 | 45                           WRANGEL    | DATAMINING

 

Las tablas con keys de tipo character son mucho más fácil trabajar, por la simple razón de que muchas veces se pueden utilizar los códigos en sí mismos y de esta manera evitamos escribir una gran cantidad de JOINs en las tablas principales. Con las Keys de tipo integer, usted siempre debe hacer JOINs a la tablas maestras para obtener un valor significativo para mostrar al usuario. Este tipo de tabla es muy fácil de leer cuando se está depurando el código de programación, así como también cuando se desarrollan consultas (querys), por ejemplo:

– El ejemplo de key tipo character es bastante simple:
SELECT profesor, asignatura FROM profesor_x_asignatura

– La key tipo integer absolutamente requiere joins
SELECT x.profesor_id,x.asignatura_id,
      p.nombre,  a.descripcion
FROM profesores_x_subasgnaturas x
 JOIN profesores p ON x.profesor_id = p.profesor_id
 JOIN asignaturas  a ON x.asignatura_id = a.asignatura_id

 

A menudo se puede escuchar a la gente decir que no les gustan los SQL porque son complicados, y resulta muy complejo hacer tantos JOINs. Razón por la cual es importante conocer sobre si las personas se pierden en una selva JOINs, por los malas sugerencias de la REGLA ABSOLUTA, las cuales te indican utilizar siempre Primary Key de tipo integer.

Por otra parte, si se está utilizando algún tipo de sistema de ORM (Motores de persistencia ó Mapeo Objeto- Relacional en una herramienta de programación Orientado a Objeto, tal como PHP) que trata de protegerse de cualquier codificación de SQL, el problema básicamente que se presentará es que seguirán apareciendo muchas tablas complicadas en el código. De una manera u otra, se deben introducir datos que le indiquen al sistema ORM cómo obtener las descripciones, lo cual no sería problema si las Primary Keys fueran de tipo character con valores significativos.

Con lo tratado en los párrafos anteriores, podemos ver el sorprendente hecho de que las Primary Key de tipo integer nos pueden frenar en muchas situaciones. No sólo no nos aportan ninguna ventaja de performance (rendimiento), sino que en realidad perjudican el rendimiento. La razón es debido a que requieren JOINS en casi todas las consultas.

Una consulta con tres (03) tablas con dos joins siempre será mucho más lento que una consulta de una (01) tabla sin join. Si se está utilizando un sistema de ORM que no hace uso de JOIN, sino que hace recuperaciones por separado, entonces usted tendrá tres (03) ida y vuelta al servidor en lugar de uno (01), y esto puede ser más complicado si se tienen queries con nested loop (consultas con bucle anidado), por lo cual el rendimiento será simplemente catastrófico. Todo esto es algo irónico ya que a menudo se escucha a la gente repetir de manera dogmática “Vamos a utilizar primary key de tipo integer por motivos de rendimiento …”

Regla de Oro 2: Utilizar Primary Key tipo Character para Tablas Maestras Pequeñas

Muchos programadores de bases de datos utilizan el término “tabla maestra” para referirse a cualquier tabla que listan las propiedades de las cosas que tienen cierta permanencia, tal como clientes, profesores, estudiantes, asignaturas escolares, países, zonas horarias, artículos (SKU) y cualquier otra cosa que se pueda ser listada y utilizada muchas veces en otros lugares. En general, una tabla maestra tiene más columnas que una tabla de referencia sencilla.

Algunas tablas maestras son pequeñas y no cambian a menudo. Siguiendo con nuestro ejemplo de una Aplicación de Gestión de Escuela, la lista de los profesores es un buen ejemplo de una tabla maestra pequeña. En comparación con la lista de los estudiantes, que es mucho más grande y cambia cada año, la tabla de los profesores en la mayoría de las escuelas (excepto para universidades grandes) tendrá sólo unos pocos cambios cada año.

En este tipo de tablas es bueno permitir al usuario introducir valores para la primary key de tipo character, si así lo desean. Algunas escuelas pueden estar interesadas en que se les permita elegir sus propios códigos, tales como como ‘WRANGEL’ para “Wilfredo Rangel”, mientras que otras pudieran decir: “¿Por qué tengo que hacer un código, no puede el sistema hacer esto?”

Para este tipo de tablas siempre resulta muy útil definir la primary key como una columna de tipo character, y luego permitir una cierta flexibilidad en la forma en que se genera los valores de la misma.

Las formas más comunes de generación de códigos incluyen:

  1. Dejar que el usuario cree su propio código
  2. Generar un código de alguna otra columna o columnas, al igual que la primera letra del nombre, más 5 letras del apellido, además de tres dígitos numéricos. (Esto solía ser muy popular en las décadas pasadas).
  3. Generar un número.

La idea clave aquí es seguir las necesidades de sus usuarios. La opción 2 es una de los más útiles, ya que permite aprovechar lo mejor de ambos mundos.

Regla de Oro 3: Usar Primary Key de tipo Integer para Tablas Maestras Grandes

Algunas tablas maestras son grandes o cambian a menudo, o ambas. En nuestro ejemplo de una Aplicación de Gestión de Escuela, la lista de los estudiantes va a cambiar todos los años, con muchos estudiantes que van y vienen. Otro ejemplo es el consultorio de un médico que tiene pacientes que van y vienen todo el tiempo. Para este tipo de tablas es mejor usar las primary keys de tipo Integer (número entero), dado que:

  • A diferencia de las  tablas maestras pequeñas (como profesores) o las tablas de referencia (como asignaturas), una primary key con valor tipo código probablemente no tendrá ningún significado para el usuario final, por lo que aquí no aplica este argumento para ser implementado.
  • A diferencia de las tablas de referencia, es probable que la tabla maestra tenga muchas más columnas y probablemente muchas veces formarán parte de QUERYS con muchos JOINs a muchas otras tablas. Esto significa que nuestra otra gran razón para usar primary key con valores de tipo códigos con la finalidad de evitar JOINs, tampoco se justifica.
  • Tampoco es realista, pensar que los usuarios finales hagan códigos para tablas maestras grandes, y dado que el valor de los códigos no tendrán ningún significado, ¿por qué molestar al usuario final con este trabajo?
  • Por otro lado, escribir algoritmos para generar códigos únicos implicará más dificultades y en virtud de que el código no tiene ningún valor, ¿ para qué molestarse?

Regla de Oro 4: Usar Primary Key de tipo Integer para Tablas de Transacciones

Muchos programadores de bases de datos utilizan el término “tabla de transacciones” para representar cualquier tipo de tabla que registra algún tipo de interacción o evento entre las tablas maestras. Por ejemplo, en un sistema de eCommerce las tablas que representan al carrito de compra son todas tablas de transacción, las cuales registran la compra de artículos por cliente. En nuestro ejemplo de una Aplicación de Gestión de Escuelas, los registros de las clases tomadas por los estudiantes son transacciones, porque registran las interacciones específicas entre los estudiantes y profesores.

Para estas tablas las primary key de tipo Integer auto-generada tiende a ser la más útil. No hace falta presentar algún argumento para esto porque a la mayoría de los programadores les resulta evidente por sí mismo. Debería ser suficiente con decir que cualquier intento de utilizar una clave compuesta (como cliente + fecha) siempre termina causando un gran problema al limitar lo que se puede registrar, así como también para la recuperación de consultas y para agrupar u ordenar un conjunto de resultados de consulta.

Dado que el motor de consultas de SQL del Servidor de Base de Datos (DBMS) utiliza el índice de la primary key para las búsquedas y comparaciones, implementar una primary key de tipo Integer, sencilla o de una columna y sin significado es la técnica más recomendada.

Regla de Oro 5: Usar Multi-Column Key (claves compuesta con multi-columna) en Tablas de tipo Referencias Cruzadas

Una buen diseño de base de datos siempre debe contar con algunas tablas de tipo referencia cruzadas. Una tabla de referencias cruzadas, es cualquier tabla que lista varios registros acerca de cómo las tablas maestras se relacionan entre sí. Estas tablas son muy útiles para la validación de las transacciones.

La primary key de una tabla de referencia cruzada es una combinación de las foreign keys de las tablas maestras. Para este tipo de tabla no es necesario crear una columna adicional, tal como primary key de tipo Integer o Character.

PROFESOR-ASIGNATURA      REFERENCIA CRUZADA

Profesor | Asignatura
—— —– + ————-
ASILVA |DATABASE
ASILVA|ALGORITMOS
ASILVA| REDES
WRANGEL | SISTEMAS
WRANGEL | BIGDATA
WRANGEL | DATAMINIG

 

El SQL para esta tabla se parecería a algo como esto:

CREATE profesores_x_asignaturas TABLE
  profesor char (10)
 ,asignatura char (10)
 ,primary key (profesor, asignatura)

 ,foreing key (profesor) references profesores (profesor)
 ,foreing key (asignatura) reference asignaturas (asignatura))

 

Este enfoque nos permite validar las asignaciones de clases profesores de manera que no sea asignado ningún profesor para dictar una asignatura para la cual no está calificado. Usar una nueva columna como primary key no nos permite esta validación y por lo tanto nos conduce a un código más complicado y propenso a errores.

Regla de Oro 6: Usar given keys (claves orígenes) para Non-Insert Imports

Es muy común que para el desarrollo de nuevos sistemas, estos deben interoperar con el core system empresarial existente en las organizaciones. Un caso típico son los sistemas de eCommerce, con los cuales obtendrá una lista de artículos e incluso de los clientes de los  principales sistemas empresariales de la organización (ERP, CRM, SCM).

Para algunas de estas tablas, nuestros nuevos desarrollos nunca crean nuevos registros. Un ejemplo muy común es una tabla de productos en un eCommerce, la cual se carga desde otro sistema.

Para estas tablas, la técnica más sencilla es utilizar la primary key existente en la tabla del sistema origen. Cualquier otra implementación significa mucho más trabajo sin una motivación clara que justifique el esfuerzo.

Regla de Oro 7: Usar Surrogate Key para Tablas Import / Export

En contadas ocasiones se puede tener el caso de que para una tabla de un nuevo desarrollo de sistema, los valores originales provienen de otra tabla de otro sistema, pero a diferencia del caso anterior este nuevo desarrollo puede generar nuevas registros o filas en la tabla y puede que tenga que replicar estos nuevos registros en el sistema original.

Un ejemplo clásico de esto es una lista de clientes. Recientemente desarrollé un Website en el cual la lista de clientes se actualiza desde el sistema de gestión de clientes (CRM). Sin embargo, el Website también permite registrar nuevos clientes de manera online. Por lo tanto, ambos sistemas están generando registros  de clientes y deben sincronizarse regularmente para reconciliar una sola base de datos.

En estos casos se recomienda usar una la técnica de primary key tipo Integer para esta tabla, dado que si se aplica la Regla de oro 3, esta va a ser una tabla maestra grande. Además, esto permite asegurar que el valor de la nueva primary key nunca será nulo, será no compuesta, con un tipo de datos simple (entero) y un valor sin significado (entero auto-generado). A esta técnica de primary key se le conoce como surrogate key o clave sustituta. Cada valor sustituto representa o permanece en el mismo registro de su fila asociada en la tabla origen. El valor sustituto carece de sentido. El esquema de numeración suele comenzar con 1 para la primera fila de la tabla, e incrementa con cada fila añadida a esa tabla. Los valores de la columna sustituta son generados por el sistema y cada valor es único dentro de la tabla.

El concepto más importante aquí es que no se debe intentar combinar la primary key nueva del sistema y la primary key de la tabla original. Mantenga la primary key de la tabla original en su propia columna, a continuación se debe indexar y utilizar para las actualizaciones, pero no intente de establecer este campo como una columna única. El nuevo desarrollo debe hacerse cargo de la surrogate key.

Regla de Oro 8: Utilizar un Object ID en todas las tablas

Años atrás, cuando la gente estaba entusiasmada con el concepto de “Bases de datos Objeto-Relacionales“, se implementó el término “object id” para referirse a una columna que contiene un valor único sin ningún significado. La misma idea existe con diferentes nombres, pero ahora “Object ID” es un término que la mayoría de la gente entiende por lo cual es un término que se puede utilizar.

En muchas casos, los programas pueden ser más simples si se agrega un object id para en cada tabla, además de la primary key. Un object id es útil específicamente para el código de interfaz de usuario. Si utiliza un object id entonces es más fácil escribir sentencias de UPDATE y DELETE, y es más fácil de escribir framework o código ORM que hacen estas operaciones de SQL para nosotros.

Si usted está implementando estas reglas de oro en su proyecto, o piensa hacerlo, entonces es importante que no utilice el object id como primary key, ni como foreign key. Si utiliza un object id como primary key perderá los beneficios que aportan las primary key de tipo Character, descritos anteriormente.

Además, si usted sigue estas reglas en sus proyectos, significa que las tablas de transacción tendrán tanto una primary key de tipo Integer auto-generada, tal como CART_ID y un objeto id auto-generado. Algunos programadores se molestan por esto,  porque no le gusta la idea de que dos columnas parecen estar cumpliendo la misma función, por lo cual tratan de salvar una columna. Pero en lo personal, no me parece una traba, porque esto ayuda a escribir aplicaciones robustas, y como ya no estamos 1985, donde se justificada,  pues unos 10MB de disco duro costaban cientos de dólares.

Regla absoluta 1: Nunca Nulos

Ningún valor de primary key puede ser nulo, ni puede hacer nada para que la primary key sea nula. Se trata de una regla inviolable del modelado relacional respaldada por ANSI y por los sistema de gestión de base de datos relacional (RDBMS). Cuando se designa una primary key, los principales motores de bases de datos la señalan como NOT NULL a todas las columnas que forman la key. Null es una condición desconocida. Cuando un valor de tabla es nulo, significa una de varias cosas. Puede significar que el valor es desconocido, que el valor no es relevante, o que no sabe si el valor es relevante.

Regla absoluta 2: Brevedad

Dado que el motor de SQL utiliza el índice de la primary key para las búsquedas y comparaciones, es recomendable elegir primary key cortas, de una columna si es posible. Utilizar primary key compuestas (combinación de datos de dos o más tablas basadas en valores comunes en combinación de columnas) para la recuperación de consultas y para agrupar u ordenar un conjunto de resultados de consulta es más costoso.

Cuanto más breves sean las entradas de índice, más rápido puede realizar las búsquedas y comparaciones del motor de SQL. Por ejemplo, puede utilizar la columna de la primary key para la recuperación de consultas (SELECT * FROM PROFESORES WHERE profesor_id = 72) y para la modificación de datos (UPDATE PROFESORES SET nombre = “Antonio Silva” WHERE profesor_id = 72). Además, puede utilizar la columna de la primary key para agrupar u ordenar un conjunto de resultados de consulta (SELECT * FROM PROFESORES ORDER BY nombre).

Regla absoluta 3: Simplicidad

Al momento de elegir una primary key, se debe tener en cuenta buscar candidatos que no contengan valores con espacios incorporados, ni caracteres especiales o peor aún, diferencias entre mayúsculas y minúsculas. Los motores de SQL reconocen y discriminan la diferencia entre letras mayúsculas y minúsculas en una consulta, por lo que hay que evitar candidatos a primary key que contengan valores de mayúsculas mixtas porque estas entradas son difíciles de trabajar con consultas SQL y sentencias join. Escribir “Diplomado en Marketing Digital & Redes Sociales” cada día en docenas de querys es mucho más difícil y propenso a errores que escribir “2”.

Regla absoluta 4: Tipos de datos

Los tipos de datos enteros (números) son la mejor opción para la primary key, seguidos por los tipos de datos de caracteres de longitud fija. Los motores de SQL procesan los valores de tipo de datos numéricos más rápido que los valores de tipo datos de carácter porque convierten los caracteres a valores equivalentes ASCII antes de procesar, lo cual es un paso adicional.

Los tipos de datos de caracteres de longitud fija son mejores que los tipos de datos de caracteres de longitud variable porque los motores de SQL deben descomprimir los datos de caracteres de longitud variable antes de procesar los datos. Este paso extra consume un tiempo de procesamiento valioso.

Regla absoluta 5: Sólo valores atómicos

Esto no es más que una “regla de oro”, con la particularidad que yo la sigo al pie de la letra. En realidad, es parte de la Primera Forma Normal, en la cual se establece que los valores de las columnas deben ser atómicos o indivisible. Otra forma de decirlo es que la columna no debe tener “sub-valores” anidados en ella, es decir que el valor sea una concatenación de valores.

Se puede incluir esta regla aquí, en lugar de en la Primera Forma Normal, porque cuando la mayoría de los programadores violan esta regla, están haciendo las primary key mediante la combinación de diferentes valores entre sí.

Este error es muy común entre los desarrolladores de bases de datos, tratar de crear inteligencia o significado en la primary key. La razón más convincente para no crear una primary con significado, es que la columna de primary key que se crea para ser descriptiva podría quedar obsoleta. Volviendo al ejemplo de la Aplicación de Gestión de Escuelas, si tenemos una lista de los estudiantes que toman clases en un año escolar, es posible que tenga una columna de primary key concatenada de esta manera:

CLASS_CODE                     | ESTUDIANTE
————————–      + —————
ASILVA-2017-DATABASE     | NAI
ASILVA-2017-ALGORITMO   | PCLAYBORNE
WRANGEL-2017-SISTEMAS  | JBOONE
WRANGEL-2017-BIGDATA    | NAI

 

implementar esta solución presenta varios problemas graves:

  1. No se puede utilizar una foreign key para validar los subvalores, por lo cual se debe escribir un código para una validación manual.
  2. Si se requiere actualizar el valor de una parte de la clave porque cambio en el sistema, esto representará un desafío de dimensiones enormes, dado que la actualización de las distintas ocurrencias se debe realizar vía codificación.
  3. Para recuperar los subvalores del primary key se requiere de un código adicional, ya sea en el SELECT o el código del lado del cliente. Si los valores se encuentran en columnas separadas no es necesario hacer nada de esto.

Regla absoluta 6: No utilizar Valores Mágicos

Otra regla que sigo es con regularidad es: “nunca tener valores mágicos”. Un valor mágico es un valor en una columna que causa algún resultado no evidente. He incluido esta regla porque la mayoría de los programadores que la rompen, lo hacen mediante acciones especiales de codificación en duro sobre la base de los valores de las primary keys en las tablas de referencia y tablas maestras.

A manera de ejemplo veamos la tabla de profesores, donde uno de los valores de profesor es algo así como “SUSTITUTO”, y el programa está codificado para hacer un montón de cosas diferentes cuando se presenta este valor. Los valores mágicos son malos porque el código es más difícil de depurar. Puede que no sea obvio para un programador que algún valor especial de la columna de PROFESOR, causará que ocurrieran acciones especiales. Pero si usted tiene una columna llamada FLAG_SUBSTITUTE entonces cualquier programador que deba hacer mantenimiento al código escrito por otra persona, tendrá un un escenario mucho más fácil para hacerlo.

Los valores mágicos también confunden a los usuarios finales. Puede parecer obvio para nosotros que el valor “SUSTITUTO” en la columna de PROFESOR significa sustituto, pero si este valor hace que otras cosas ocurran, y estamos acostumbrados al hábito de tener estos valores en un montón de tablas, entonces el efecto resultante puede ser montones y montones de llamadas telefónicas de usuarios confundidos y un gran problema para el equipo de desarrolladores de software.

Por último, los valores mágicos nos limitan. Si se utiliza el valor “SUSTITUTO” como un solo profesor en la tabla de profesores, entonces ¿cómo se mantiene un registro de los de las docenas de sustitutos que puede contratar la escuela en un año? El usuario final se puede quedar atascado aquí, por lo cual deben utilizar lápiz y papel. Es mucho mejor permitir que puedan registrar los “SUSTITUTO”  como un miembro regular de la facultad mediante una columna FLAG_SUBSTITUE.

A manera de conclusión.

En este artículo, se ha reseñado que puede haber muchos beneficios prácticos para el uso de diferentes tipos de Primary Key para diferentes tipos de tablas. Utilizando el tipo correcto de Primary Key para el tipo correcto de la tabla, se puede conseguir un código más simple y de mejor rendimiento, ya sea directamente en el código SQL o al utilizar un sistema de ORM.

Es importante que recuerde, que su aplicación siempre seguirá la misma estructura que las tablas. Si las tablas están bien diseñadas, el código puede ser pequeño, conciso, eficiente y robusto. Debido a que el diseño de la tabla es tan importante, lo mejor es conocer bien los diferentes tipos de tablas que se pueden utilizar, tales como:de referencia, maestra, referencia cruzada, de transacción, y de esta manera, proceder a construir las Primary Key.

Buenas primary key son esenciales para un buen diseño de base de datos, pues le permiten consultar y modificar cada fila de la tabla individualmente sin cambiar otras filas en la misma tabla. Cuando evalúe los candidatos para la clave principal de una tabla, siga estas reglas:

  • La clave primaria debe consistir en una columna en la medida que sea posible.
  • El nombre debe significar lo mismos desde hoy a 5 años.
  • El valor de los datos debe ser NOT NULL y permanecer constante en el tiempo.
  • El tipo de datos debe ser un entero o un carácter corto, de ancho fijo.
  • Si está utilizando un tipo de datos de carácter, la primary key debe excluir diferenciación entre mayúsculas y minúsculas, así como también espacios y caracteres especiales que sean difíciles de recordar.

Puede utilizar los criterios de la Tabla 1 para evaluar cada candidato primary key. El candidato que coincida con todas las mejores respuestas es la mejor opción como primary key de la tabla. Si ningún candidato cumple todos los criterios de mejor respuesta, considere la posibilidad de crear una surrogate primary key para la tabla.

TABLA 1: Criterios para la evaluación de candidatos para la primary key

Condición La mejor respuesta
No Nulo: ¿El valor del candidato será nulo? no
Cardinalidad: ¿El valor del candidato es más que una sola columna? no
Simplicidad: ¿El valor del candidato contiene espacios embebidos, caracteres especiales o mayúsculas diferenciales? no
Tipo de datos: ¿Es el valor del candidato algo distinto de un tipo de datos de tipo de número o longitud fija? no
Valor con significado: ¿El valor del candidato contiene alguna inteligencia o tiene algún significado? no
Variabilidad: ¿Es probable que el valor del candidato cambie? no

 

Share this post

Comments (3)

  • Josefina Martinez Reply

    Muy buenas tardes..tenia entendido que en el momento de utilizar comillas, eran simples.
    de acuerdo a este tema encontré esto y necesito solo aclararlo….
    …….. Por ejemplo, puede utilizar la columna de la primary key para la recuperación de consultas (SELECT * FROM PROFESORES WHERE profesor_id = 72) y para la modificación de datos (UPDATE PROFESORES SET nombre = “Antonio Silva” WHERE profesor_id = 72). Además, puede utilizar la columna de la primary key para agrupar u ordenar un conjunto de resultados de consulta (SELECT * FROM PROFESORES ORDER BY nombre)…….

    Muchas gracias

    4 marzo, 2018 at 1:06 pm
    • Wilfredo Rangel Reply

      Saludos,

      Gracais por tu interes.

      Efectivamente, eso es correcto!!!

      Éxitos Totales!!

      7 julio, 2018 at 7:25 am
  • Manuel Efraín Oropeza Chang Reply

    excelente articulo

    7 marzo, 2018 at 7:46 pm

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *