Afin d'optimiser ma base, est 'il plus interressant de stocker un tableau avec l'enssemble des choix dans ma base. Ainsi, je n'aurais qu'une seule entrée enregistrée par utilisateur.
En soi non, car tu brises le modèle relationnel et tu saisis une information qui n'est exploitable que par l'application (et difficilement éditable par le DBA, avec çà).
Actuellement, si un utilisateur choisi toutes les options de ma liste, j'enregistre une centaines d'entrées dans ma base de données.
Ce n'est pas forcément un problème. Dans le pire des cas, si tu répertories 1000 utilisateurs et qu'ils sélectionnent tous la totalité des options, tu obtiendras une table de 100 000 entrées. En considérant que tu utilises des IDs sur 32 bits pour coder ton numéro d'utilisateur comme ton numéro d'option, ta table atteindra péniblement les 800 Ko. Le moindre *.ogg traînant sur ton disque en fait minimum le triple ...
D'autre part, si tu stockes tes infos dans un tableau, tu gagneras sur le l'ID utilisateur, certes (gain minimum de 50%), mais tu stokeras à chaque fois le tableau entier ! Ce qui revient précisément à faire ce que tu cherches à éviter.
En outre, il faut garder à l'esprit que les informations des différents tuples sont stockées de manière contigüe sur ton disque. Donc stocker un tableau de dix entiers dans un enregistrement ou insérer dix entrées dans une table d'une colonne de type entier va se traduire exactement de la même façon sur ton support.
C'est le mauvais coté de la programmation orientée objet, d'ailleurs. On considère l'entité en tant que telle mais on en oublie sa nature, et on devient beaucoup plus sensible au cardinal de son ensemble qu'à son coût unitaire en ressources.
La seule chose qui va être déterminante dans le choix de l'architecture de ta base est la distribution de tes données dans le sens statistique du terme. Nombre d'utilisateurs à choisir des options, nombre moyen d'options sélectionnées par utilisateurs, scoring de tes options (important) : est-ce que 80 % des utilisateurs sélectionnent 20 % des options proposées ou bien est-ce uniformément réparti ? etc.
Par contre, l'intérêt du champ unique est d'éviter d'avoir à recourir à une boucle Fetch(). Certains langages permettent de charger un resultset en une opération mais, bien souvent; celle-ci est implémentée à son tour par une boucle dans le niveau d'abstraction immédiatement inférieur, donc le gain n'est pas réel. En transférant le tout d'un coup tu réduis de manière significative le trafic réseau et la charge système. Par contre, ce n'est palpable que si tu fais la même opération pour des centaines d'utilisateurs à la suite.
En résumé, cela peut-être efficace d'un point de vue technique pure, à condition de rester dans un système statique. Si tu veux par exemple faire évoluer ta base et empêcher certains utilisateurs de sélectionner certaines options, tu pourras aisément poser une contrainte d'intégrité pour que le SGBD rejette les entrées illégales. Si tu utilises un format particulier, tu court-circuites ces fonctionnalités et tu restes donc seul garant de la cohérence de ta base.
# Mauvaise idée.
Posté par Obsidian . En réponse au message Stocker un tableau dans une base sql. Évalué à 6.
En soi non, car tu brises le modèle relationnel et tu saisis une information qui n'est exploitable que par l'application (et difficilement éditable par le DBA, avec çà).
Ce n'est pas forcément un problème. Dans le pire des cas, si tu répertories 1000 utilisateurs et qu'ils sélectionnent tous la totalité des options, tu obtiendras une table de 100 000 entrées. En considérant que tu utilises des IDs sur 32 bits pour coder ton numéro d'utilisateur comme ton numéro d'option, ta table atteindra péniblement les 800 Ko. Le moindre *.ogg traînant sur ton disque en fait minimum le triple ...
D'autre part, si tu stockes tes infos dans un tableau, tu gagneras sur le l'ID utilisateur, certes (gain minimum de 50%), mais tu stokeras à chaque fois le tableau entier ! Ce qui revient précisément à faire ce que tu cherches à éviter.
En outre, il faut garder à l'esprit que les informations des différents tuples sont stockées de manière contigüe sur ton disque. Donc stocker un tableau de dix entiers dans un enregistrement ou insérer dix entrées dans une table d'une colonne de type entier va se traduire exactement de la même façon sur ton support.
C'est le mauvais coté de la programmation orientée objet, d'ailleurs. On considère l'entité en tant que telle mais on en oublie sa nature, et on devient beaucoup plus sensible au cardinal de son ensemble qu'à son coût unitaire en ressources.
La seule chose qui va être déterminante dans le choix de l'architecture de ta base est la distribution de tes données dans le sens statistique du terme. Nombre d'utilisateurs à choisir des options, nombre moyen d'options sélectionnées par utilisateurs, scoring de tes options (important) : est-ce que 80 % des utilisateurs sélectionnent 20 % des options proposées ou bien est-ce uniformément réparti ? etc.
Par contre, l'intérêt du champ unique est d'éviter d'avoir à recourir à une boucle Fetch(). Certains langages permettent de charger un resultset en une opération mais, bien souvent; celle-ci est implémentée à son tour par une boucle dans le niveau d'abstraction immédiatement inférieur, donc le gain n'est pas réel. En transférant le tout d'un coup tu réduis de manière significative le trafic réseau et la charge système. Par contre, ce n'est palpable que si tu fais la même opération pour des centaines d'utilisateurs à la suite.
En résumé, cela peut-être efficace d'un point de vue technique pure, à condition de rester dans un système statique. Si tu veux par exemple faire évoluer ta base et empêcher certains utilisateurs de sélectionner certaines options, tu pourras aisément poser une contrainte d'intégrité pour que le SGBD rejette les entrées illégales. Si tu utilises un format particulier, tu court-circuites ces fonctionnalités et tu restes donc seul garant de la cohérence de ta base.
Bon courage.