Une table de jonction est-elle la solution correcte pour stocker des données historiques pour de nombreux attributs?

Question

Je suis en train de concevoir une application web qui stocke les métriques SEO relatives aux sites web. Il existe environ 50 mesures relatives à chaque site Web qui sont calculées et stockées chaque jour. Je dois être en mesure de suivre les changements pour chacune de ces mesures au fil du temps. J'ai conçu le schéma suivant basé sur ma compréhension de la normalisation. Il semble que la table de jonction (tbl_website_metric) devienne très grande très rapidement. Je voudrais savoir si c'est le schéma optimal pour cela ou si j'ai fait des erreurs de conception.

CREATE TABLE `tbl_website` (
    `id` INT NOT NULL AUTO_INCREMENT , 
    `name` VARCHAR(100) NOT NULL , 
    `domain` VARCHAR(100) NULL , 
    `url` VARCHAR(100) NULL , 
    PRIMARY KEY (`id`)) 
ENGINE = InnoDB; 

CREATE `tbl_metric` (
    `id` INT NOT NULL AUTO_INCREMENT , 
    `name` VARCHAR(45) NOT NULL , 
    `description` VARCHAR(100) NULL , 
    PRIMARY KEY (`id`)) 
ENGINE = InnoDB; 

CREATE `tbl_website_metric` (
    `id` INT NOT NULL AUTO_INCREMENT , 
    `metric_id` INT NOT NULL , 
    `website_id` INT NOT NULL , 
    `created` TIMESTAMP NULL , 
    `value` VARCHAR(45) NULL , 
    PRIMARY KEY (`id`) , 
    CONSTRAINT `fk_tbl_website_metric_tbl_metric1` 
    FOREIGN KEY (`metric_id`) 
    REFERENCES `tbl_metric` (`id`) 
    CONSTRAINT `fk_tbl_website_metric_tbl_website1` 
    FOREIGN KEY (`website_id`) 
    REFERENCES `tbl_website` (`id`)) 
ENGINE = InnoDB; 

Answer 1

Votre conception de DB semble bon pour le scénario; quelques suggestions si:

1. Je ne suis pas sûr combien de sites votre application pour stocker les statistiques, mais sinon plus de quelques milliers, pensez à modifier tbl_website. id à SMALLINT UNSIGNED. Cela vous permettra de stockage 65535 sites

2. De même, puisque vous avez environ 50 mesures, il est logique de changer tbl_metric. id à TINYINT UNSIGNED. Cela vous permettra de stocker 255 mesures

3. Je pense que les FK ont créé automatiquement des index sur les colonnes respectives, mais si ce n'est pas le cas, veuillez envisager de créer des index pour tbl_website_metric. metric_id et tbl_website_metric. website_id

S'il vous plaît noter que pour 1 et 2, vous aurez également besoin de modifier les données-types en conséquence pour tbl_website_metric. metric_id et tbl_website_metric. website_id.

Je ne suis pas sûr de la taille de la table de jonction, mais MySQL est très capable de gérer de grandes tables. Quoi qu'il en soit, ce sera une bonne approche d'envisager de purger les entrées qui sont obsolètes de tbl_website_metric, ou peut-être les archiver dans une autre table.

Je voudrais également suggérer une autre approche.Si 1) vos métriques sont assez statiques, en ce sens que les statistiques sont souvent ajoutées ou supprimées, et 2) que les statistiques sont les mêmes pour tous les sites Web, vous pouvez également stocker vos statistiques dans des colonnes:

CREATE TABLE `tbl_website_metric` (
    `id` INT NOT NULL AUTO_INCREMENT, 
    `website_id` INT NOT NULL, 
    `created` TIMESTAMP NULL, 
    `metric_1` VARCHAR(45) NULL, 
    `metric_2` VARCHAR(45) NULL, 
    `metric_3` VARCHAR(45) NULL, 
    `metric_4` VARCHAR(45) NULL, 
    ... 
    ... 
    `metric_50` VARCHAR(45) NULL 
); 

Cela signifie une seule insertion et une sélection unique par site Web. Plus réduira le nombre d'enregistrements dans la table de N fois, où N = nombre de métriques.

Espérons que ça aide.

Answer 2

cela semble plutôt bien.

index sur les ID devrait garder votre performance en bonne santé.

Answer 3

semble correct en général ... quelques petits problèmes, principalement en ce qui concerne les types de colonnes:

• il n'y a aucune raison pour une clé primaire explicite dans tbl_website_metric OMI. Un index unique sur (metric_id, website_id, created) doit être suffisamment
• tbl_website_metric.created devrait être un DATE (arrêts 1 octet et est nécessaire pour l'unicité de l'indice)
• value doit être un littéral?
• vous avez déclaré des contraintes de clé étrangère pour metric_id et website_id; tout cela bien sûr présente certains avantages, cela signifie aussi des problèmes de verrouillage, cf http://www.mysqlperformanceblog.com/2006/12/12/innodb-locking-and-foreign-keys/

HTH