Discussion :

[cladoo]

Bonjour,

voilà nous devons stocker en base un nombre non connu (mais borné) de variables, la personne avant moi avait commencé à créer autant de rubriques que de variables possibles mais le boulot est gigantesque et c'est compliqué à gérer.
Je pense utiliser des rubriques de type tableau dans HyperFile.

1) Existe-t-il des limitations particulières, des choses à savoir sur ce type stocké en base ?

2) est-ce que les temps de réponse sont bons via les requêtes ?

3) Tout point de vue est apprécié

Merci!

[SevenSoftware]

Bonjour,

Je n'ai jamais utilisé les rubriques tableau.
Par contre, je créerais un fichier Variables (Clé,NomVar,Contenu)
avec une clé du type CléFichierPrincipal+NomVariable

On peut aussi y ajouter une rubrique "type de variable" et n rubriques contenu
pour les différents types (Chaine, Monétaires, entiers,...)

L'avantage de cette solution c'est qu'elle fonctionne pour toutes les BDD.

Bon dev

Patrick

[frenchsting]

Je plussoie ta méthode. Cela me paraît le plus simple. Je n'ai jamais, non plus, utilisé de champ tableau.

Egalement pour l'écriture de requêtes qui du coup seront plus standard. Au cas où tu voudrais changer de système de bdd...

[cladoo]

Merci pour ce précieux conseil.

Je vais essayer de tester pour voir ce que ça peut donner, mais en effet les aspects positifs sont nombreux!

Toute remarque / conseil supplémentaire pour construire ce type de fichier est bienvenu, j'en suis à la conception de la base, donc pas encore de contraintes (mise à part de bosser en HyperFile)

[vmolines]

D'où provient la contrainte d'HyperFile étant donné que c'est un nouveau projet ?

Je mise sur un décideur/chef incompétent et obstiné.

[cladoo]

D'où provient la contrainte d'HyperFile étant donné que c'est un nouveau projet ?

Je mise sur un décideur/chef incompétent et obstiné.

Disons que jusqu'à aujourd'hui ils ont toujours bossé en HF, ils en sont contents et ils connaissent donc c'est plus par peur de l'inconnu je pense.
C'est une toute petite structure, et au final on est plus bidouilleurs que vrais informaticiens, donc la politique c'est de rester sur ce qu'on "maîtrise" je pense.

[leonidas34]

J'ai travaillé sur un projet dans lequel on avait largement utilisé les rubriques de type tableau.
J'ai eu à revoir ce qui avait été fait justement, je vais vous expliquer pourquoi.

- Tout d'abord, avec les rubriques de type tableau, il y aura un jour des limitations de taille, c'est à dire que ce qui est représenté dans le tableau sera limité en taille et le jour ou on veut passer en illimité, ca va poser problème.

- il n'y a pas de découpage en entités merisiennes correctes et là aussi cela peut poser problème.

- Par contre c'est avantageux en vitesse d’exécution il me semble : même si on charge tout dans une seule ligne, il n'y a pas de jointures dans les requêtes.

Je ne conseillerais pas d'utiliser les rubriques de type tableau.

pour info, j'ai eu à refaire le cœur d'une application, avec de nouveaux fichiers dans une conception bien merisienne cette fois-ci. Il a fallu migrer les données dans des dimensions totalement différentes du fait que l'on est passé de deux fichiers à 8 (plusieurs rubriques tableaux dans chaque fichier).
Dans cette application, il avait été ajouté des rubriques de type tableaux au fil des besoins dans deux fichiers.
J'ai dû refaire tout cela et tout devait être géré par des classes...

[cladoo]

J'ai travaillé sur un projet dans lequel on avait largement utilisé les rubriques de type tableau.
J'ai eu à revoir ce qui avait été fait justement, je vais vous expliquer pourquoi.

J'ai dû refaire tout cela et tout devait être géré par des classes...

Merci pour ce retour précieux. Il est vrai qu'on manque d'utilisateurs de ce genre de rubrique sur Windev...

Pouvez-vous me dire si vous avez opté pour la solution préconisée par SevenSoftware : un fichier Variables (Clé,NomVar,Contenu) ??

Merci beaucoup!

[leonidas34]

Non, on n'a pas opté pour la solution préconisée par sevensoftware car ce n'est pas ce qui m'a été demandé. La solution de sevensoftware doit avoir aussi ses limites. Il est plus sûr selon moi de refaire la modélisation de manière tout à fait classique, car là on ne sera pas limité.
On a re-modélisé et les fichiers contenant des rubriques de type tableau ont été "éclatés". Le seul désavantage de cette façon de faire, c'est la dégradation des performances, qui n'est pas très importante par ailleurs.

[vmolines]

Imaginons qu'on souhaite des attributs "dynamiques" sur une entité personne

Personne = {IDPersonne, ...}
AttributPersonne = {IDAttribut, NomAttribut}
AttributPersonneValeur = {#IDPersonne, #IDAttribut, ValeurAttribut}

Les points sur lesquels il faut être vigilant lorsqu'on utilise une modélisation par méta-données :

- La gestion des types de données des attributs si on souhaite un typage fort. Avec le modèle simple que je propose, ValeurAttribut a un type fixe choisi au départ.
- La gestion de l'ajout d'attribut -> que fait-on des personnes déjà saisies sans valeur pour le nouvel attribut ?
- Chaque attribut dynamique n'étant pas une entité dans le modèle de données, il faut réserver cet usage pour les éléments qui n'ont pas vraiment besoin de figurer dans le modèle de données. On pourrait faire n'importe quelle base avec un même méta modèle mais c'est le serpent qui se mort la queue car notre méta modèle ne définit plus rien en soi (voir l'article de SQLPro que j'ai mis en lien).

[cladoo]

L'article est vraiment intéressant et la méthode que je ne connaissais pas aussi, je pense effectivement l'utiliser dans le projet : merci à tous !

[gardangel]

Salut cousins,

J'utilise les tableaux partout... vraiment partout. La référence à une ligne est assignée à une classe. Lors d'un chargement d'un fichier, c'est un tableau à dimension variable que j'assigne. Impliqué avec une notion d'indicateur, on retrouve un compromis rapide et flexible sur l'utilisation des données.

Je peux vous dire que c'est vraiment très rapide. Effectivement, il faut faire attention à créer un débordement lors d'un remplissage d'un tableau. L'utilisation d'un critère spécifique (un filtre) à tout niveau permet d'en maximiser l'utilisation.

C'est mon avis.

[cladoo]

@gardangel : merci pour votre retour. Utilisez-vous les rubriques tableau en Hyperfile ou un autre SGBDD ?

La référence à une ligne est assignée à une classe. Lors d'un chargement d'un fichier, c'est un tableau à dimension variable que j'assigne. Impliqué avec une notion d'indicateur, on retrouve un compromis rapide et flexible sur l'utilisation des données.

- Je ne comprends pas ce que veut dire "la référence à une ligne est assignée à une classe" : avez-vous un exemple pour m'aider à comprendre ?
- Idem pour la "notion d'indicateur" ?
- Un tableau à dimension variable ? je ne comprends pas, ne doit-on pas fixer dans l'analyse le nombre d'éléments maximum supportés par la rubrique tableau ?

L'utilisation d'un critère spécifique (un filtre) à tout niveau permet d'en maximiser l'utilisation.

- Là encore pouvez-vous me donner un exemple pour l'utilisation d'un filtre ?

Merci beaucoup!

[leonidas34]

J'ai eu à faire la même chose. Des classes avec des tableaux d'éléments et chaque élément d'une tableau correspondait avec une ligne d'un fichier.
Mais comme je l'ai déjà dit, c'était pour justement supprimer les rubrique de type tableau dans hyperfile.
Cela fonctionnait bien.

Il faut cependant faire attention au niveau performances, car le chargement d'un tableau de tableau de tableau de tableau, x fois, peut être long, les données étant récupérées sur des fichiers, si le modèle de données comporte trop de fichiers dépendant les uns à la suite des autres.