Toute base de données a en gros 2 types de tables — dimensions et faits :

1. Les dimensions sont les tables de configuration. Ces tables ne sont pas modifiées fréquemment et sont généralement une seule valeur d'instantané actuelle (éventuellement avec quelques modifications d'historique - détaillées ci-dessous). Les opérations les plus courantes sont les modifications apportées à la table. On peut également les considérer comme Config ou Masters.
2. Les faits sont des tableaux qui augmentent presque linéairement avec le temps. Généralement, ces entités sont générées régulièrement avec le temps, les mises à jour des faits générés ne sont pas courantes et font généralement référence aux dimensions pour plus de contexte.

Lors de la conception d'un schéma de base de données, certaines des directives suivantes aident à le faire correctement.

Normale d'abord

Que la base de données soit SQL ou NoSQL, il est utile de penser aux entités/objets et donc aux tables une fois dans une perspective de schéma normalisé. Le schéma normalisé donne de la clarté sur les entités, les relations et les champs. La dénormalisation ou la conversion en NoSQL à partir de cela peut être simple et peut être une conception consciente.

Miroir des entités du monde réel

Même si les cas d'utilisation/rapports ne sont pas clairs, les entités de schéma doivent refléter le cas d'utilisation réel. Un tel schéma est généralement robuste.

L'un des cas suivants est généralement le cas pour identifier et créer différentes entités et donc des tables :

1. Entités logiquement séparées qui peuvent exister indépendamment et potentiellement sans aucun lien les unes avec les autres - par exemple, ensemble de données et station
2. Avoir des relations plusieurs-à-plusieurs ou des relations un-à-plusieurs les uns avec les autres - par exemple pour une entreprise de commerce électronique, des commandes et des clients.

Si un champ est utilisé dans les requêtes, la recherche ou le tri, ajoutez des index pour celui-ci par défaut. Les index simples doivent être activés pour ces champs par défaut, car ils présentent un avantage maximal. Ne pas ajouter d'index doit être un choix conscient, pas l'état par défaut.

Utiliser les bons types de champs

1. Énumération vs types de chaîne pour les champs avec un ensemble fixe de valeurs d'option : les énumérations sont implémentées sous forme d'octets, donc prennent moins d'espace (par exemple, 1 à 4 octets de long octet/long/int vs chaîne de 128 octets), sont plus rapides/rapides sur les index et recherches. Pour les grandes tables, les exigences d'espace et de performances s'additionnent. Utilisez les énumérations par défaut.
2. Type de clé primaire (ID) : Performances et stockage - il est toujours conseillé d'utiliser une clé de taille fixe - c'est-à-dire des entiers ou des UUID.
3. Champs de table communs : Certains champs sont suggérés dans toutes les entités ORM qui peuvent changer — c'est-à-dire created_at, updated_at, created_by, updated_by. De plus, pour les entités qui peuvent souvent avoir des liens de clé étrangère et qui sont rarement supprimées, il est proposé d'utiliser des suppressions réversibles.

La requête de Drishti peut être complexe, impliquant plusieurs jointures. Les bases de données sont optimisées pour les jointures et les calculs en mémoire. Dans la mesure du possible, exécutez ces jointures ou ces calculs dans la base de données, soit par des ajouts à la couche ORM, soit par une requête appropriée, soit par une refonte du schéma. En règle générale, on ne devrait examiner les grandes jointures de résultats dans le code d'application que là où la base de données ne peut pas le faire en mémoire, par exemple pour les jointures entre bases de données.

Quand ajouter des tables d'historique ?

Tout système basé sur les transactions nécessite une journalisation de base de toutes les modifications pour les entités clés. Cela s'applique particulièrement aux tables Dimension, car celles-ci sont configurées/modifiées via les API.

Il existe 2 manières de les entretenir :

1. Maintenez une abstraction générique pour le changement d'attribut, dans laquelle chaque ligne de cet historique des changements pointe vers le type d'entité, l'attribut, l'ID d'entité, l'ancienne valeur et la nouvelle valeur. Avantage : Ne nécessite pas de nouvelle table par entité.
2. Maintenez une table d'historique par entité pour chaque modification de la valeur. Avantage : Capturez en tant que transactions atomiques plusieurs modifications de champs, en les montrant comme telles au client. Ainsi, la notion de transaction telle qu'elle est effectuée par l'utilisateur sur le frontend ou autre est conservée.