Qualquer banco de dados tem basicamente 2 tipos de tabelas — dimensões e fatos:

1. As dimensões são as tabelas de configuração. Essas tabelas não são alteradas com frequência e geralmente são um único valor instantâneo atual (possivelmente com algumas alterações no histórico — detalhadas abaixo). As operações mais comuns são edições na tabela. Pode-se também pensar neles como Config ou Masters.
2. Fatos são tabelas que aumentam quase linearmente com o tempo. Normalmente, essas entidades são geradas regularmente com o tempo, as atualizações dos fatos gerados não são comuns e geralmente se referem a Dimensões para obter mais contexto.

Ao projetar o esquema do banco de dados, algumas das diretrizes a seguir ajudam a fazer isso corretamente.

Normal primeiro

Independentemente de o banco de dados ser SQL ou NoSQL, é útil pensar nas Entidades/Objetos e, portanto, nas tabelas uma vez a partir de uma perspectiva de esquema normalizado. O esquema normalizado fornece clareza sobre as entidades, relacionamentos e campos. A desnormalização ou conversão para NoSQL a partir disso pode ser direta e pode ser um projeto consciente.

Espelhar entidades do mundo real

Mesmo que os casos de uso/relatórios não sejam claros, as entidades do esquema devem refletir o caso de uso do mundo real. Esse esquema geralmente é robusto.

Qualquer um dos seguintes são geralmente os casos para identificar e criar diferentes entidades e, portanto, tabelas:

1. Entidades separadas logicamente que podem existir de forma independente e potencialmente sem qualquer ligação umas com as outras — por exemplo, conjunto de dados e estação
2. Tenha relacionamentos muitos-para-muitos ou relacionamentos um-para-muitos entre si — por exemplo, para uma empresa de comércio eletrônico, pedidos e clientes.

Se houver um campo sendo usado em consultas, pesquisa ou classificação, adicione índices para ele por padrão. Índices simples devem estar ativados para esses campos por padrão, pois eles oferecem o máximo benefício. Não adicionar um índice deve ser uma escolha consciente, não o estado padrão.

Use os tipos de campo corretos

1. Tipos de enumeração versus string para campos com um conjunto fixo de valores de opção: As enumerações são implementadas como byte, portanto, ocupam menos espaço (por exemplo, 1–4 byte de comprimento byte/long/int versus string de 128 bytes), são mais rápidas/rápidas em índices e pesquisas. Para tabelas grandes, os requisitos de espaço e desempenho se somam. Use enumerações por padrão.
2. Tipo de chave primária (ID): Desempenho e armazenamento - é sempre aconselhável usar uma chave de tamanho fixo - ou seja, números inteiros ou UUIDs.
3. Campos de tabela comuns: Alguns campos são sugeridos em todas as entidades ORM que podem mudar — ou seja, created_at, updated_at, created_by, updated_by. Além disso, para entidades que muitas vezes podem ter ligações de chave estrangeira e raramente são excluídas, propõe-se o uso de exclusões reversíveis.

A consulta de Drishti pode ser complexa, envolvendo várias uniões. Os bancos de dados são otimizados para junções e cálculos na memória. Sempre que possível, execute essas junções ou cálculos no banco de dados — seja por meio de adições à camada ORM, consulta adequada ou redesenho de esquema. Como regra geral, deve-se observar grandes junções de resultados no código do aplicativo apenas quando o banco de dados não puder fazer isso na memória — por exemplo, para junções entre bancos de dados.

Quando adicionar tabelas de histórico?

Qualquer sistema baseado em transação precisa de registro básico de todas as alterações para as entidades-chave. Isso se aplica especialmente às tabelas Dimension, já que elas são configuradas/modificadas por meio das APIs.

Existem 2 maneiras pelas quais eles podem ser mantidos:

1. Mantenha uma abstração genérica para alteração de atributo, em que cada linha neste histórico de alteração aponta para o tipo de entidade, atributo, id de entidade, valor antigo e novo valor. Vantagem: Não requer uma nova tabela por entidade.
2. Mantenha uma tabela de histórico da entidade para cada alteração no valor. Vantagem: Captura como transações atômicas múltiplas alterações de campos, mostrando-as como tal para o cliente. Assim, o conceito de uma transação feita pelo usuário no frontend ou não é preservado.