[Access 2007 - Nouveautés] Les champs multi-valués

[Tofalu]

Introduction
Voici ce qu'on peut lire dans l'aide en ligne de la nouvelle version d'Access :

Nouveauté : Vous pouvez créer un champ qui contient plusieurs valeurs. Supposons que vous souhaitez stocker une liste de catégories auxquelles vous avez attribué un élément. Dans la plupart des systèmes de gestion de base de données et dans les versions précédentes d'Access, vous devez établir une relation plusieurs-à-plusieurs. Dans Office Access 2007, vous avez déjà fait le plus difficile une fois que vous avez choisi un champ à plusieurs valeurs. Ce type de champ convient tout particulièrement lorsque vous utilisez Office Access 2007 pour manipuler une liste SharePoint contenant l'un des types de champ à plusieurs valeurs de Windows SharePoint Services. Office Access 2007 est compatible avec ces types de données.

Illustrations


Questions :

Aux débutants : Cette nouvelle fonctionnalité semble t'elle faciliter vos développements ?

Aux experts : Seriez vous prêt à adopter cette technique, comment voyez vous son impact sur les futurs développements ?

Ressources

Un article complet de démonstration http://warin.developpez.com/access/multivalue/

Exprimez-vous, nous vous attendons !

[Mariboo]

Si j'ai bien compris, Cette nouvelle fonctionnalité remet complétement en question la méthode structurelle habituelle pour une base de données : les relations "plusieurs à plusieurs"..... cela peut effectivement chambouler les futures méthodes de développement !
C'est à essayer ... mais personnellement je ne sais pas si je vais m'en servir .... j'ai bien peur que ça mette le bazare dans la structure des BD ...

A voir ...

[Lou Pitchoun]

Voici mes impressions "à chaud", il y en aura certainement d'autres "à froid"

Au niveau conception (comme tu le soulignes dans ton article), ça va changer les habitudes.
Personnellement, le seul intérêt que je trouve à cette méthode c'est la suppression des relations n, n (moins de tables). Il est vrai, et tu l'as montré dans l'article, que ce n'est pas bien plus compliqué d'ajouter des enregistrements avec DAO. Mais si une application doit en pâtir au niveau performance (requêtes), je ne pense pas que j'utiliserai les champs multivalués.

Au niveau développement, il faudra prendre l'habitude de développer avec cette vision de conception. Et il faudra un temps d'adaptation.
Est ce que cela vaut vraiment le coup ? Il peut y avoir un intérêt : un gain au niveau de l'ajout d'enregistrements.

Imaginons un formulaire avec comme source la table classe (on choisi la classe) et un sous formulaire en mode feuille de données pour ajouter les élèves par une simple coche. Avec les champs multivalués : y a presque rien à faire. Sans les champs multivalués : il y a un peu de boulot derrière pour arriver au même résultat. Seulement, est ce que le temps gagné à développer vaut le cout de perdre du temps en traitement des requêtes ?? Personnellement je me verrais mal un utilisateur venir et me dire : "c'est trop long. il faut améliorer les temps d'éxécution". Et là je lui dit quoi ? "Et bien il faut que je recommence à 0" ou alors "Ca vous plait pas ??" en me disant intérieurement : fait c**** lui, y veut me faire perdre du temps à me casser la tête à développer.

[Captain_JS]

Peut etre suis-je un peu con mais j'ai du mal à voir pourquoi les requetes risquent d'etre plus longuess...

Dans mon esprit les champs multi valués permettent de récupérer en 1 requete ce qu'avant on récupérait en 1 requete .. bon là ok, sauf qu'avant on fesait des jointures donc Access se tapait plusieurs requetes en interne.
Maintenant aussi il en fait plusieurs en interne, sauf qu'il travaille avec son nouveau systeme (je ne sais pas comment appeler l'imbrication d'une table dans une autre). Et on droit de supposer que si Microsoft a créé ça ça doit (j'espère que ça l'est) etre plus rapide qu'avant.

Maintenant j'avoues que je ne l'ai pas encore tester, mais si des personnes ont fait des tests de perfos qu'ils les fassent partager j'en serais ravi

[Tofalu]

Les test figurent dans l'article donné en lien

[Captain_JS]

Oups désolé je n'avais pas lu jusqu'à le fin

Au vue des performances c'est vrai que j'ai un peu de mal à saisir l'intéret des champs multis-valués pour de telles pertes de perfos
Autant construire "à la main" et traiter directement des champs "complexes" plutot que d'utiliser des champs multis-valués ...

Y'a possibilité de modifier mon vote ?

[drinkmilk]

Je pense que ce concept de champs multi-valués est un réel besoin pour les concepteurs / utilisateurs de bases de données. Je ne sais pas si Access est un pionnier en la matière (ça existe sur Oracle, non ?), mais on peut raisonnablement penser que si les performances ne sont pas encore au rendez-vous, elles le seront certainement très prochainement.

En plus, Access 2007 n'en est qu'à sa version beta 2, non ?

[DonJR]

oui
ca peut etre utile pour les relations plusieurs-a-plusieurs, cela peut representer une évolution ,
car il est vrai que les relations plusieurs-a-plusieurs ressemblent parfois plus a un bidouillage fouilli je trouve (surtout plus la base grossie), et cette fonctionnalie peut etre alors utile et rendre plus clair la "relation" dans certains cas

personnellement c'est a voir, maintenat il est vrai egalement qu'il ne faut pas que les performances en prennent un coup
est ce que SQL Server va integrer cette fonctionnalite dans l'avenir ?

[Maxence HUBICHE]

Pour ma part, je suis très partagé sur l'intérêt de la chose.
Je suis toujours parti du prinicpe qu'au lieu de prémacher le boulot, il fallait expliquer le pourquoi du comment.

A lire les commentaires que je viens de lire, je confirme mon point de vue.

Lorsqu'on analyse un besoin initial, on détermine les entité qui entrent dans le projet.
Ensuite, on s'occupe des associations à faire entre les entités.
C'est alors qu'on se retrouve avec des entités porteuses d'attributs... ou pas.

Quid des entités porteuses d'atributs ?
Cette nouvelle fonctionnalité n'y répond pas.

Quid des performance de la nouveauté ?
Bof... même s'il est vrai qu'il ne s'agit que d'une version beta.

Que se passe-t-il si la modélisation n'est pas correcte (ce qui est fréquent dans des projets faits par des non professionnels, cible principale d'Access) et que le concepteur ne parvienne plus à suivre son projet, qu'il soit repris pas un informaticien de la boîte, le résultat ?
=> "Ouais ! Voilà ! Access, c'est de la daube, c'est même pas normalisé"
Or, si Access n'ajoute cette fonctionalité (amusante) que dans la version 2007, il ne faut pas oublier qu'il y a la même chose dans 4D depuis.... pfiou !

Donc, pour faire bref :
- Réelle avancée ? => A MON avis : Non
- Favorable à la renommée d'Access ? => on verra bien à l'usage, mais j'en doute. Pour un utilisateur lambda : Oui. Pour un Informaticien pur jus : Tout au contraire.

[argyronet]

Envoyé par Maxence HUBICHE

Or, si Access n'ajoute cette fonctionalité (amusante) que dans la version 2007, il ne faut pas oublier qu'il y a la même chose dans 4D depuis.... pfiou !

Mouais, c'est exact !
D'ailleurs, File Maker Pro (Claris à l'époque euh... 1991) adoptait aussi ce concept fort convivial à cette époque du fait qu'Access n'était pas vraiment né. Donc pour trouve un logiciel de conception de BDD rapide et simple, c'était idéal.
Ayant lâché File Maker depuis Thiers, je ne sais pas si dans leur dernière version, ils adoptent encore ce concept.
Là, cette nouveauté, pour moi, n'apporte rien de probant à la version 2007.

[ypicot]

Envoyé par argyronet

Ayant lâché File Maker depuis Thiers, je ne sais pas si dans leur dernière version, ils adoptent encore ce concept.

Pour répondre à ta question : oui, les multi-valuées existent toujours dans Filemaker version 8. C'est d'ailleurs comme cela que sont stockées les listes permettant les choix multiples.
Il y a même (GROSSE NOUVEAUTE... enfin, pour filemaker) des variables, qui peuvent être elle aussi multivaluées.

Quand à l'utilisation, je serais moins tranché : un petit dev (genre 5 ou 10 jours) avec relativement peu de données : ok pour les multivaluées.
Grosse appli avec une normalisation d'enfer : niet.

Bref, un outil de plus, qui a ses avantages et ses inconvénients. Vous utilisez les cadres d'objet dans tous vos développements, vous ? Moi, seulement quand ca m'arrange.

Une solution n'est valable que dans un contexte donné.

Yvan

[Tofalu]

Pour les champs mutli-valué, je ne suis pas parvenu à les traiter avec ADO. Avec DAO, la valeur d'un champ mutli-valué retourne un recordset alors que sous ADO, la porpriété Value génère une erreur La portabilité de tels champs est donc largement remise en question

[Lou Pitchoun]

Envoyé par Tofalu

La portabilité de tels champs est donc largement remise en question

Comme l'on dit certains : access 2007 n'est qu'en beta 2.
Pour ceux qui sont intéressés par cette fonctionnalité : ils devront patienter.

[Maxence HUBICHE]

Envoyé par Tofalu

Pour les champs mutli-valué, je ne suis pas parvenu à les traiter avec ADO. Avec DAO, la valeur d'un champ mutli-valué retourne un recordset alors que sous ADO, la porpriété Value génère une erreur La portabilité de tels champs est donc largement remise en question

Remarque bien que c'est dans la BASES DE DONNEES access que tu trouves l'info, et non dans les PROJETS.
Or, DAO est adapté pour les BASES DE DONNEES Access. ADO est utilisé par défaut pour les PROJETS.
Donc, pas étonnant.

Tout ceci ne change pas mon point de vue sur cette 'nouveauté'...

[Tofalu]

Oui mais ADO permet aussi d'attaquer une base Access, notament quand l'applicatif n'est pas Access. Beaucoup de développeur VB, Delphi, etc ne travaille qu'avec ADO, va leur expliquer qu'ils vont devoir revenir à DAO pour utiliser les nouvelles fonctionnalités.

[Maxence HUBICHE]

On va partir dans un autre débat ... je le sens...
Quoi qu'il en soit, qu'ils utilisent un autre applicatif, langage ou tout ce qu'on voudra, DAO est une bibliothèque.
ils auraient donc pu l'utiliser immédiatement.
D'autre part, la bibliothèque DAO étant plus performante en terme de rapidité sur de l'Access...

Bref...

[random]

un nouvel outil à mettre dans la boîte ?
bravo !

Que ceux qui ne veulent pas ou qui ne peuvent pas l'en sortir l'y laissent.

Il ne répond pas aux normes ? tant mieux, elles pourront évoluer.

Il déplaira aux "informaticiens" ? tant mieux, ils retourneront jouer avec leurs
normes et pendant ce temps là les choses pourront avancer.

Il bafoue le relationnel ? il y a belle lurette que je gère moi-même relations et intégrité.

Il n'est pas encore performant sur de grosses bases ? tant pis, nous le réserverons pour certaines bases quand nous saurons l'utiliser.

ado lui résiste ? tant mieux,j'ai toujours pensé que dao était le bon choix.

[Tofalu]

il est vrai que pour un petit jeu de données c'est bien. En plus l'interface graphique utilisée est super ergonomique. Il est clair que sur certaines relation, cela fera gagner du temps au développeur. Notamment pour tout ce qui est liste de valeurs (liste qui ne bougeront pas et ne nécessiteront pas de table).

[Tententai]

Pour apporter un point de vue de non informaticien pur jus, j'ai un avis assez mitigé sur cette nouveauté. Je mets de côté les problèmes de performances dans le cadre d'une utilisation "amateur".

Il est clair que pour un utilisateur qui fait sa petite base perso, c'est bien pratique de ne pas avoir à se tapper des relations n n (que ce soitau niveau conception de la base, mais aussi des mises à jour / ajout de données, c'est plus compliqué de bien penser à toutes les tables impliquées).

D'un autre côté, je me souviens de quand j'ai débuté dans les bases de données relationnelles, quand on a pas eu de formation dans le domaine, devoir gérer les relations n n ça aide bien à comprendre les mécanismes d'un tel type de conception. Si on m'avait offert un outil comme les champs multi valués, ça m'aurait aidé à court terme, mais certainement embrouillé dans ma compréhension de ce qu'est une base de données relationnelle.

Donc à mon avis c'est un bon outil pour des gens qui doivent concevoir rapidement des petites bases à la demande. Ce qui au final doit représenter une partie non négligeable des utilisateurs d'Access. Mais pas pour apprendre, ni pour des applications plus complexes (j'ai un peu peur de la flexibilité de la chose en cas de refonte ultérieure de la conception).