Bonjour,

Je travaille actuellement sur un projet durant mon stage et je dois stocker des données calculées (récupérées et croisées préalablement à partir d'autres tables de la même base de données) dans une table (qui n'existe pas encore, donc je suis libre de la structurer comme je le veux).

Ma question est la suivante:

Sachant que j'ai dans les 200 données calculées à enregistrer, et ce pour chaque UL (unité laitière) que je dois traiter, et qu'il y a environ 8.000 à 10.000 UL à traiter, vaut-il mieux créer une table de 200 colonnes ( ) ou une table avec 2 colonnes (une pour le nom de la donnée, une pour la valeur) dans laquelle je stockerai indifféremment toutes ces 200 données, à moi ensuite de les récupérer selon les critères que je veux ?

Ceci entraîne en fait une question générale: qu'est-ce qui est le plus rapide ? lire des colonnes une par une ou parcourir toute une table (sachant qu'au final, elle contiendra plusieurs dizaines voire centaines de milliers d'enregistrements) ?

Je ne suis pas DBA, mais je ferai naturellement la première solution.

Si toutes tes UL ont ces données renseignées, il faut faire une table de 200 colonnes.

Si tu écoutes les design pattern (ce qu'il vaut mieux faire ), chaque table ne doit contenir qu'un et un seul type d'objet que tu relies ensuite par des tables de liaison.

En clair :

Tu crées une table de jeux d'enregistrements (en définissant les données d'un jeu d'enregistrement), mappée par un IDEnregistrement

Tu crées une table avec l'ensemble de tes unités laitières, mappée par un IDUL

Tu crées une table de liaison, mappée par un IDLiaison, qui dit tel IDEnregistrement va avec tel IDUL. L'avantage, c'est de pouvoir gérer éventuellement des liaisons n-n.

Du coup, dans ton backend, n'oublie pas de coder les fonctions d'ajout et de suppression en cascade

LSP, le manchot à la 500° page sur 2000 du manuel d'installation de JES

Oki, merci pour ses premières informations.

LSP, ce que tu me dis j'y ai pensé aussi, bien sûr. Mais tout ceci ne me dit pas ce qui serait le plus rapide... Parce que ce qui est le plus "propre", c'est évident! Mais comme c'est déjà bien dégueu leur truc

Bah si tu veux faire dans le rapide, tu codes directement tes procédures d'Add/CALL en base et tu les appelles à distance en envoyant l'objet. Ou tu fais directement des EJBs

LSP, le manchot qui cligne de l'oeil

Des EJB pour accéder à tables ??

Ben la question à se poser est simple :

Est-ce que les colonnes sont des propriétés des UL qui varient pour chaque UL (ou presque) ?

Si oui, tu peux faire ta table de 200 colonnes.