BDD : table fille ou tableau ?
muqaddar
Administrateur
Salut,
Prenons un site internet, une table "boissons" dans la base de données avec x enregistrements (des centaines, des milliers...etc), ainsi qu'un champ "goût" dans cette table.
Les goûts sont peu nombreux et ne changent jamais : acide, normal, sucré.
Je voulais avoir confirmation qu'un array "goût" avec ces 3 enregistrements est bien plus rapide à charger qu'une table fille "goûts" avec (id, name) sur laquelle pointerait un champ "gout_id" de la table boissons.
Imaginez un select dans un formulaire avec les 3 enregistrements...
Je pense donc que :
- l'array est plus rapide à charger que la table fille puisqu'il n'y a pas de relations de tables dans ce cas
- l'array est moins avantageux si on souhaite souvent mettre à jour la table des goûts (mais ce n'est pas mon cas)
- lors de requête de recherche, l'array est aussi plus rapide puisqu'il n'y aura pas à faire : "WHERE boisson.gout_id = gout.id" mais simplement "WHERE boisson.gout=1" par exemple.
J'attends juste une confirmation... ou une infirmation.
Prenons un site internet, une table "boissons" dans la base de données avec x enregistrements (des centaines, des milliers...etc), ainsi qu'un champ "goût" dans cette table.
Les goûts sont peu nombreux et ne changent jamais : acide, normal, sucré.
Je voulais avoir confirmation qu'un array "goût" avec ces 3 enregistrements est bien plus rapide à charger qu'une table fille "goûts" avec (id, name) sur laquelle pointerait un champ "gout_id" de la table boissons.
Imaginez un select dans un formulaire avec les 3 enregistrements...
Je pense donc que :
- l'array est plus rapide à charger que la table fille puisqu'il n'y a pas de relations de tables dans ce cas
- l'array est moins avantageux si on souhaite souvent mettre à jour la table des goûts (mais ce n'est pas mon cas)
- lors de requête de recherche, l'array est aussi plus rapide puisqu'il n'y aura pas à faire : "WHERE boisson.gout_id = gout.id" mais simplement "WHERE boisson.gout=1" par exemple.
J'attends juste une confirmation... ou une infirmation.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
D'accord, mais RubyOnRails ne le supporte pas via ses migrations (pour être indépendant de la BD : oracle, mysql, sqlite, posgresql...). Merci de ta réponse.