Recommandations de conception pour une table d'historique/d'audit

Question

Je dois suivre de nombreux éléments et leurs états au fil du temps.

Exemple

ItemId Location DateTime   State 
    1 Mall A 2010-02-03 07:00 on_sale 
    1 Mall A 2010-02-20 08:22 sold 
    2 Warehouse 2010-02-02 09:00 on_sale 
    2 Transit 2010-03-02 16:20 transit 
    2 Mall B 2010-03-03 10:10 on_sale 
    2 Mall B 2010-03-12 12:11 sold 

En ce moment, cela est une grande table et j'utiliser la fonction de rang pseudo de MySQL pour exécuter les requêtes.

Cependant, il est très lent. Les requêtes ne peuvent pas utiliser les index, car pour tout élément particulier, il doit trouver l'élément avec rank = 1 avant de pouvoir effectuer un filtrage.

SELECT 
    item_sorted.*, IF(@prev <> item_sorted.item_id, @rownum := 1, @rownum := @rownum+1) AS rank, 
    @prev := item_sorted.item_id 
FROM ... 

Quelles sont vos expériences dans la mise en œuvre d'une telle fonctionnalité? Quelle est la conception de base de données que vous recommanderiez? Une base de données comme les bases de données Oracle ou T-SQL serait-elle bien meilleure en raison de sa prise en charge des requêtes partitionnées?

Merci d'avance pour vos idées!

Answer 1

Permettez-moi de commencer par une question:

Quel est l'objectif principal de cette table? Pour y insérer des données ou en récupérer des données?

Deux possibilités:

• Pour insérer: Je vous recommande de normaliser cela, vous aurez beaucoup de redondance.
• Pour récupérer: C'est bon comme ça. Je recommanderais une clé de substitution pour chaque ensemble.

Si vous voulez comparer la consommation de temps, essayez d'installer PostgreSQL et voir le résultat. Vous ne devriez pas avoir besoin d'utiliser Oracle ou MS-SQL, PostgreSQL devrait être assez bon.

Je sais que ma recommandation n'a rien à voir avec le partitionnement de données, mais avoir une table similaire au travail c'est comme ça que je le fais et ça marche bien.

espoir que je pourrais aider,