2010-07-04 7 views
1

J'essaye de décider d'un schéma pour stocker des bogues de croisement de navigateur à travers tous les moteurs de rendu.Normalisation/Schéma pour classer les bogues inter-navigateurs en fonction des moteurs de rendu et des versions du navigateur?

Voici ce que j'avais à l'esprit:

table browser_engines:

id name version 
1 gecko 1.5 
2 gecko 1.7 
3 gecko 1.8 
4 gecko 1.9.0 
5 gecko 1.9.1 

table browser_versions:

id name  version engine_id 
1 firefox 3.0  4 
2 firefox 3.5  5 

browser_bugs table:

id name description engine_id 
1 ff bug    4 

Donc, si je tire la premier bogue, il serait mappé à gecko 1.9.0, donc la vue html rendrait le navigateur affecté comme Firefox 3.0.

Question 1.1: Ce schéma a-t-il un sens? Est-ce assez normalisé?

Question 1.2: Quel type de données devrait être la colonne version?

Répondre

1

Question 1.1: Ce schéma a-t-il un sens? Est-ce assez normalisé?

Hey! C'est deux questions. ;-)

Ce schéma suppose certaines choses, telles que:

  • Chaque version du navigateur ne dispose que d'un seul moteur de navigateur.
  • Chaque bug dans un moteur de navigateur donné est garanti pour affecter chaque navigateur qui utilise ce moteur.

Si l'une d'entre eux est toujours pas garantie pour être vrai, vous pourriez avoir besoin de plusieurs à plusieurs tables d'intersection.

Question 1.2: Quel type de données devrait être la colonne version?

Je voudrais aller avec VARCHAR pour expliquer "4.0 release candidate 1" et autres. J'autoriserais au moins une longueur de 30.

1

Je créerais une table de moteur (c'est-à-dire une ligne pour gecko, et un FK de browser_engine to engine), de même qu'une table de navigateur. Cela réduira les besoins de stockage et accélérera les requêtes. Je pense aussi à stocker la version dans les champs majeur/mineur/révision pour faciliter l'interrogation de 'tous les bogues de la révision 2.5 ou précédente' ("10.0" < "2.5" - donc les chaînes ne conviennent pas pour une telle requête).