Cualquier base de datos tiene en términos generales 2 tipos de tablas: dimensiones y hechos:

1. Las dimensiones son las tablas de configuración. Estas tablas no se modifican con frecuencia y, por lo general, son un único valor de instantánea actual (posiblemente con algunos cambios en el historial, que se detallan a continuación). Las operaciones más comunes son las ediciones de la tabla. También se puede pensar en estos como Config o Masters.
2. Los hechos son tablas que aumentan casi linealmente con el tiempo. Por lo general, estas entidades se generan regularmente con el tiempo, las actualizaciones de los hechos generados no son comunes y, por lo general, se refieren a Dimensiones para obtener más contexto.

Al diseñar el esquema de la base de datos, algunas de las siguientes pautas ayudan a hacerlo correctamente.

normal primero

Independientemente de si la base de datos será SQL o NoSQL, es útil pensar en las Entidades/Objetos y, por lo tanto, en las tablas una vez desde una perspectiva de esquema normalizado. El esquema normalizado brinda claridad sobre las entidades, las relaciones y los campos. La desnormalización o conversión a NoSQL desde esto puede ser sencilla y puede ser un diseño consciente.

Reflejar entidades del mundo real

Incluso si los casos de uso/informes no están claros, las entidades del esquema deben reflejar el caso de uso del mundo real. Este esquema suele ser robusto.

Cualquiera de los siguientes son generalmente los casos para identificar y crear diferentes entidades y, por lo tanto, tablas:

1. Entidades separadas lógicamente que pueden existir de forma independiente y potencialmente sin ningún vínculo entre sí, por ejemplo, conjunto de datos y estación
2. Tener relaciones de muchos a muchos o relaciones de uno a muchos entre sí, por ejemplo, para una empresa de comercio electrónico, pedidos y clientes.

Si hay un campo que se usa en consultas, búsquedas u ordenaciones, agregue índices para él de forma predeterminada. Los índices simples deben estar activados para estos campos de forma predeterminada, ya que tienen el máximo beneficio. No agregar un índice debe ser una elección consciente, no el estado predeterminado.

Usa los tipos de campo correctos

1. Enumeración frente a tipos de cadena para campos con un conjunto fijo de valores de opción: las enumeraciones se implementan como byte, por lo tanto, ocupan menos espacio (p. ej., 1 a 4 bytes de longitud byte/largo/int frente a cadena de 128 bytes), son más rápidas en índices y búsquedas. Para mesas grandes, los requisitos de espacio y rendimiento se suman. Usa enumeraciones por defecto.
2. Tipo de clave principal (ID): rendimiento y almacenamiento: siempre es recomendable utilizar una clave de tamaño fijo, es decir, números enteros o UUID.
3. Campos de tabla comunes: se sugieren algunos campos en todas las entidades ORM que pueden cambiar, es decir, created_at, updated_at, created_by, updated_by. Además, para las entidades que a menudo pueden tener enlaces de clave externa y rara vez se eliminan, se propone que se utilicen eliminaciones temporales.

La consulta de Drishti puede ser compleja e involucrar múltiples uniones. Las bases de datos están optimizadas para combinaciones y cálculos en memoria. Siempre que sea posible, ejecute estas uniones o cálculos en la base de datos, ya sea a través de adiciones a la capa ORM, consultas adecuadas o rediseño del esquema. Como regla general, uno debe mirar las uniones de resultados grandes en el código de la aplicación solo donde la base de datos no puede hacerlo en la memoria, por ejemplo, para uniones entre bases de datos.

¿Cuándo agregar tablas de historial?

Cualquier sistema basado en transacciones necesita un registro básico de todos los cambios para las entidades clave. Esto se aplica especialmente a las tablas de Dimension, ya que estas se configuran/modifican a través de las API.

Hay 2 formas en las que se pueden mantener:

1. Mantenga una abstracción genérica para el cambio de atributos, donde cada fila en este historial de cambios apunte al tipo de entidad, atributo, id de entidad, valor anterior y valor nuevo. Ventaja: no requiere una nueva tabla por entidad.
2. Mantenga una tabla de historial por entidad para cada cambio en el valor. Ventaja: Captura como transacciones atómicas múltiples cambios de campo, mostrándolo como tal al cliente. Por lo tanto, se conserva el concepto de una transacción realizada por el usuario en la interfaz o de otra manera.