Big Data, Science des données, aide à la décision en entreprise, business intelligence, data warehouse, reporting, OLAP, web analytics, data visualization, data mining, internet des objets, informatique cognitive, intelligence artificielle...

Abonnez-vous gratuitement à Decideo !


Decideo

 


Comparatif entre Digdash et QlikView


Rédigé par par Jean-Marc DUPONT, 6IT le 13 Avril 2011

La nouvelle génération des outils de BI est en plein essor en ce moment. Qlikview a été l'un des précurseurs, mais ses concepts étaient apparamment en gestation chez ses concurrents car d'autres solutions n'ont pas tardé à voir le jour.



Jean-Marc DUPONT, fondateur de 6 IT
Jean-Marc DUPONT, fondateur de 6 IT
Rappelons d'abord les principes de ces nouveaux outils :
  • L'affichage des données n'est plus figé et conditionné à l'envoi de requêtes à une base de données (relationnelle ou OLAP) mais tout ou partie des données est chargée en mémoire (du poste client et/ou du serveur), ce qui donne une grande réactivité aux tableaux de bord et une interactivité qui permet d’accélérer l'analyse et la prise de décision.
  • Tout ou partie des axes d'analyse (ou des dimensions) est disponible pour l'utilisateur, qui va pouvoir progressivement raffiner son analyse.
    Un indicateur va pouvoir être analysé selon l'ensemble de ses axes d'analyse, à la demande.
  • Les tableaux de bord / graphiques / tableaux sont interactifs : un clic sur une zone d'un graphique va permettre de zoomer (descendre dans le détail) sur une donnée ou filtrer les informations sur cette donnée
    Associée à la disponibilité des données en mémoire, ceci permet à l'utilisateur d'analyser très rapidement ses informations et identifier les problèmes / axes d'amélioration
  • Des fonctions de simulation sont fournies qui permettent de faire varier un ou plusieurs paramètre et analyser en temps réel leur impact sur les autres indicateurs

En dehors de Qlikview, je travaille aujourd'hui avec la solution Digdash et j'ai voulu faire un comparatif entre les 2 outils qui se rapprochent assez en termes de fonctionnalités.
Je me suis également appuyé sur les compétences d'un partenaire intégrateur de Qlikview pour valider certains points de Qlikview que je ne connaissais pas forcément en détail.


Architecture technique

Il y a tout d'abord une grosse différence en termes d'architecture technique, qui peut être un premier facteur de choix en fonction du contexte de l'entreprise :
  • Qlikview repose sur une architecture Windows, que ce soit pour son client riche (logiciel Windows) ou ses serveurs applicatifs et Web (Windows Server / IIS)
    Ce qui le destine en priorité (mais pas seulement) aux entreprises ayant déployé leur SI sur une architecture Windows
    Si Qlikview est déployé sur un serveur Web IIS, les tableaux de bord sont disponibles sur navigateur web (Internet Explorer en priorité, mais aussi Firefox, Chrome et Safari, avec un moins bon rendu)
    A noter que toutes les fonctionnalités d'affichage ne sont pas disponibles sur tous les navigateurs Web.
    A noter également que Qlikview travaille actuellement sur un client web full HTML qui sera disponible sur les plate-formes mobiles (smartphones et tablettes).
  • Digdash repose sur un serveur applicatif développé en java, fonctionnant par défaut avec Tomcat et Apache comme serveur Web
    Le client fonctionne sur un navigateur web moderne (Firefox, Chrome, Safari et Internet Explorer 7, 8 et 9)
    L'ensemble est donc déployable au choix sur des serveurs Windows ou Linux et des terminaux Windows, Mac, iPad, Android, ...

Internationalisation

En termes de déploiement international, Digdash est conçu de base pour fonctionner en mode multilingue : l'ensemble des libellés (axes, indicateurs) peut être défini dans diverses langues et s'adapte en fonction de la langue de l'utilisateur. Les libellés des dates varient également en fonction de la langue de l'utilisateur.

Qlikview ne gère pas nativement le multilingue. Il est cependant possible de mettre en place un mécanisme de traduction des libellés dans l'interface en les remplaçant par des fonctions retournant le texte.
Il vaut donc mieux prévoir cela dés le départ et seuls les textes sont traduits, pas les noms des champs ni des tables. On profite donc de la souplesse de l'outil pour compenser en partie une fonctionnalité importante qui manque.

Gestion des utilisateurs / des droits

Digdash gère les utilisateurs dans un annuaire LDAP embarqué ou dans l'annuaire de l'entreprise.
Les droits sont gérés sur 3 niveaux :
  • Les autorisations (Afficher un tableau de bord, Editer un tableau de bord, ...) peuvent être attribuées à un utilisateur
  • Les groupes d'autorisations permettent de regrouper des autorisations et les attribuer à un utilisateur
  • Les profils permettent de donner des accès aux sources de données (voir plus loin) et aux graphiques des tableaux de bord

Qlikview peut gérer la sécurité lui même ou se connecter à un annuaire d'entreprise (en gérant utilisateurs ou groupes).
On distinguera :
  • La sécurité au niveau du portail pour définir qui a accès à quelle application,
  • La sécurité au niveau des fonctions dans l'application (droit de rafraîchir, droit d'exporter...),
  • La sécurité pour la visibilité des éléments (affichage conditionnel des onglets ou des objets),
  • La sécurité des données pour masquer tout ou partie des informations de la base en mémoire, voir pour publier des applications réduites aux seules données autorisées.

Sources et modélisation des données

Digdash sépare clairement la notion de "Modèle de données" et la visualisation de ces données.

Les modèles de données décrivent :
  • La source des données (base de données, fichier CSV, Excel, ... mais aussi Rapport Business Objects ou Cognos, Cube OLAP),
  • les dimensions qui y sont définies (avec leurs hiérarchies éventuelles),
  • les indicateurs (bruts, ou calculés à partir des indicateurs bruts),
  • la fréquence de rafraîchissement de ces données.

Ces modèles de données sont ensuite utilisés dans les graphiques ou les tableaux. On définit ici :
  • le mode d'affichage (courbes, colonnes, camemberts, cartographie, ...),
  • les axes et indicateurs qui y seront affichés,
  • leurs paramètres d'affichage et de navigation (zoom, filtre, ...).

On assemble enfin les graphiques et les tableaux dans les pages du tableau de bord.

On conçoit donc plusieurs modèles de données (qu'on pourrait appeler "cubes") élémentaires et indépendants et on les utilise au gré des besoins au sein du tableau de bord.
Le lien entre les différentes sources de données se fera, si besoin, par le nom des axes d'analyse communs aux sources de données.
La conception et la maintenance s'en trouvent grandement simplifiées.

Qlikview, quand à lui, va un peu loin dans la partie alimentation des données, à l'aide d'un langage propriétaire de scripting.
Les relations entre les données sont faites principalement par le nom des "colonnes" de chaque "table" ou requête. L'unicité des noms des colonnes dans le modèle doit être assuré ou résolu à l'aide d'alias.
Pour des modèles de données sources complexes, le script à écrire peut vite représenter plusieurs pages, qu'il faudra bien prendre garde de commenter sous peine de maintenance difficile.
Le schéma des données ainsi constitué définit la source des futurs graphiques et tableaux de bord. On ne définit pas à ce niveau les colonnes qui constitueront les axes (dimensions) et les indicateurs. Cela devra être fait dans chaque objet du tableau de bord.
De même, les éventuels indicateurs calculés devront être dupliqués s'il y a besoin de les afficher dans plusieurs graphiques ou tableaux.
A noter que les formules de calculs utilisées dans les graphiques ou tableaux peuvent être mutualisées sous forme de variable (un peu à la façon de macro). C'est là aussi profiter de la souplesse du produit mais ce n'est pas une fonctionnalité mise en avant.

Visualisation des données

Les possibilités de paramétrage offertes par Qlikview sont beaucoup plus riches que celles de Digdash. On sent que le logiciel a pas mal d'années d'expérience et que les paramètres ont été ajoutés au fur et à mesure.
Ils sont répartis dans une dizaine d'onglets.
Le logiciel aurait à mon avis besoin d'un nettoyage car il n'y a pas toujours de logique dans le positionnement des paramètres dans les onglets et en fonction du graphique utilisé, le choix des paramètres est tellement riche qu'on ne sait plus trop quel paramètre choisir pour réaliser le besoin. On s'habitue petit à petit mais la prise en mains s'en trouve ralentie.

Digdash, au contraire, est plus simpliste : il lui manque certains paramètres mais c'est en contrepartie la garantie d'une productivité plus grande et d'une prise en mains plus rapide.

Les 2 outils proposent des listes permettant de filtrer les données sur les différents axes d'analyse disponibles dans le modèle. Ces listes sont positionnables dans les pages.
Digdash propose également, par défaut, d'afficher les listes dans une "barre de filtres", en haut de la page. Les filtres affichés dans cette barre sont paramétrables. Si une hiérarchie a été définie sur l'axe d'analyse (ex : année / mois / jour), les différents niveaux d'analyse sont disponibles sur une même liste.

Il est également possible, dans Digdash, de spécifier un filtre pour chaque objet graphique ou tableau, qui sera utilisé à lors du premier affichage de la page, libre ensuite à l'utilisateur de modifier le filtre.
Il n'y a pas d'équivalence dans Qlikview car tous les objets sont liés entre eux donc filtrés ensemble (sauf exception car on peut verrouiller des objets simplement ou utiliser les fonctions de filtrage : cf. ci dessous)

La comparaison de 2 membres d'un même niveau de hiérarchie (ex : mois M vs mois M-1), passe dans les 2 cas par la création d'indicateurs calculés :
  • dans Digdash, cela se fait à l'aide d'un assistant graphique qui permet de définir le filtre pour chaque indicateur calculé (=> "mois M" = mois en cours, "mois M-1" = mois en cours - 1)
  • dans Qlikview, cela se fait à l'aide d'une syntaxe de formule (les fameux "set analysis"), qui n'est pas triviale et peut rapidement devenir difficilement maintenable
    Par exemple (cas très simple) : Sum({$<cpt_mois={"-1"}>} CA)

Digdash intègre un graphique cartographique, lié à une dimension hiérarchique de type géographie (ex : Département, Région, Pays), que l'on paramètre en reliant chaque niveau de la hiérarchie à un niveau de la cartographie.
La carte est de fait interactive : elle permet de zoomer par exemple sur un pays, d'afficher le détail par région, puis par département d'une région.

Qlikview passe par une intégration de cartes Google Maps, sur lesquelles on affiche des symboles, plus ou moins gros ou de couleurs différentes en fonction de la valeur d'un indicateur.
Il est également possible de zoomer sur la carte et on peut aussi mettre en place un système de choix de la granularité (département, région, pays, ...), mais avec Google Maps ce dernier mécanisme demande un peu de travail préparatoire et ici encore c'est la souplesse du produit qui le permet mais pas une fonctionnalité native.
Il existe également des solutions externes telles que celle proposée par GeoQlik, par exemple, qui propose plus de fonctionnalités mais est un module payant, venant ainsi alourdir la facture.

Enfin, les 2 outils fournissent des fonctions de simulation, en définissant des variables, qui vont entrer dans le calcul d'indicateurs calculés, ces indicateurs étant ensuite affichés dans des graphiques ou tableaux.
La seule différence sur ce point est que la définition des variables et indicateurs calculés va se faire, pour Digdash, dans les sources de données et être utilisé dans un ou plusieurs graphiques ou tableaux, alors que pour Qlikview, la définition des indicateurs calculés va se faire dans chaque graphique / tableau qui doit afficher cet indicateur.

Un des avantages de Qlikview aujourd'hui réside dans sa fonction de recherche dans les axes d'analyse, que ne propose pas Digdash. Mais j'ai cru comprendre que cette fonction était dans la roadmap de Digdash, reste à savoir comment elle va être implémentée ...

Conclusion

On se rend compte que les 2 outils sont assez proches en termes de fonctionnalités mais diffèrent sur quelques points majeurs :

  • L'architecture technique : plus ouverte pour Digdash que pour Qlikview
  • L'internationalisation : native chez Digdash, disponible chez Qlikview en le prévoyant dés le départ et en développant les fonctionnalités à l'aide de son langage de scripting
  • Structuration des développements :
- chez Digdash : Séparation claire de la partie Modèle de données (incluant la définition des axes d'analyse et des indicateurs) et de la partie Visualisation des données
- chez Qlikview : partie alimentation des données plus riche (attention à la maintenance) mais nécessité de définir dans chaque graphique / tableau quelle colonne est un axe ou un indicateur et risque de dupliquer les règles de calcul des indicateurs calculés
  • Visualisation des données : palette de types d'affichage et de paramètres beaucoup plus riche (trop ?) chez Qlikview, en contrepartie prise en mains et productivité plus grande sur Digdash

En termes de prise en main par les utilisateurs des entreprises, je dirais que si un travail de préparation, structuré et rigoureux, a été mené par les équipes techniques, Qlikview est un outil très riche en fonctionnalités et simple de prise en main.
Digdash, quand à lui, est plus frustre en termes de fonctions graphiques, mais sa structuration et ses fonctions natives et assistées permettent de monter une plate-forme de manière très productive voire de déléguer aux utilisateurs une bonne partie de l'architecture (modèles axes d'analyse / indicateurs notamment).




Commentaires
Du plus récent au plus ancien | Du plus ancien au plus récent

17.Posté par Jean-Marc Dupont le 02/05/2011 16:05
Twitter
@Clémence D. :
Globalement, les 2 solutions sont basées sur les mêmes principes de tarification : licences à l'utilisateur
Mais avec qq différences :
Qlikview peut être utilisé selon 2 modes :
- en mode mono-poste (ou par partage de fichiers sur un serveur de fichiers) : la licence est alors tarifée par utilisateur (nommé)
- en mode "client/serveur" : il y a alors une licence pour la partie serveur et une licence par utilisateur nommé. Il existe aussi des licences au "jeton" (nb d'accès concurrents).
Le serveur est obligatoire à partir d'un certain nb d'utilisateurs.

Digdash ne possède qu'une version avec serveur et clients web : la tarification est alors par utilisateur nommé.

Dans les 2 cas, les tarifs par utilisateur sont dégressifs en fonction du nb d'utilisateurs.

16.Posté par Clémence D. le 02/05/2011 13:44
Merci pour cet article très intéressant. Les commentaires également!
Je ne connaissais pas Digdash mais ça me donne envie de le découvrir même si Qlikview m'a déjà convaincu.
Très intéressant aussi cette proposition de BI coding parties...hâte d'avoir le feedback!

Sinon quid d'un comparatif général des coûts des 2 solutions? Evidemment, cela dépend de beaucoup de paramètres, mais dans l'ensemble?

15.Posté par Alexandre Schneider le 01/05/2011 16:03
@stephane THIA

Pour compléter votre post, j'aimerai préciser que les points de 1 à 4 existent dans notre produit Prelytis LiveDashBoard, et ce depuis quelques années et sont déjà utilisés par plus de 100 000 utilisateurs. Je suis d'ailleurs ravi que DigDash essaye de promouvoir également une technologie web comme nous le faisons depuis 2002.

Enfin, cher Stéphane, je pense que vous avez raison, cela nous promet des POCs et autre maquettes intéressantes dans les shortlists ;-) Nous en avons l'habitude maintenant avec QV.

Bien à vous

14.Posté par stephane THIA le 29/04/2011 16:41
Bonjour,

Je suis entièrement d’accord avec Monsieur SAAL vis-à-vis de l’innovation et la satisfaction cliente et je connais QLIKVIEW depuis 2006, donc depuis bien moins longtemps que Romain, mais suffisamment pour effectuer des benchs.

Je ne vais pas chercher à polémiquer ou encore mettre en avant l’une ou l’autre des solutions.
De plus monsieur DUPONT a rédiger un article à ce propos.

Cependant, j’ai eu l’opportunité de croiser Digdash sur un POC effectué par une société (durant un mois et demi) et l’approche novatrice de DigDash m’a je dois dire séduit sur quelques points.

Je ne cesse de véhiculer et de défendre le fait qu’il n’y ait pas de meilleur outil, mais un outil adapté à un besoin, aussi, je me suis permis à l'issus du POC client de contacter DigDash pour effectuer mon propre POC sur les éléments que j’avais identifiés.

Qlikview est connu, et son succès parle de lui-même, et je suis certain que Romain, expert en la matière pourrait vous en parler pendant des heures !!

Sans exposer tous les points que j'ai pu testér, je souhaiterais si vous le permettez mettre en avant quelques points intéressants que j'ai pu relever dans mes tests. N’hésitez pas si vous le souhaitez, à nous expliciter les éléments équivalents des concurrents si mes lacunes sont apparentes.

Point 1 – Sources de données
Parmi les sources de données, on retrouve les connecteurs standard (BD, fichier,…) mais également les rapports des portails SAP BO XI ou IBM Cognos. Pour des clients qui ont développés des rapports BO ou Cognos et dont les rapports sont disponibles via le portail Web, Digdash a la capacité de se plugguer dessus :
Avantage :
- Le lien entre le portail BO ou Cognos (comme source de données) et DIGDASH est transparente, car le sso est embarqué. Il n’y a donc pas de sécurité à implémenter, puisque le portail DigDash s’appuie sur la sécurité du portail BO ou Cognos.
> On économise l’administration de la sécurité
- Les indicateurs présents dans le dashboard s'appuie sur les rapports BO ou Cognos. Les règles de calcul sont ainsi centralisées dans BO par exemple.

Point 2 – La mise en mémoire
Monsieur DUPONT à raison de mettre en avant la répartition de la charge entre le serveur et le client Web.
Ce que je souhaiterais compléter, c’est qu’il y a une répartition intelligence, selon qu’il s’agisse d’un navigateur web d’un ordinateur ou d’un téléphone, dont la capacité mémoire est différente.

Cependant, avant de parler de l’utilisation de données en mémoire, j’aimerai mettre un bémol sur la mise des données en mémoire :

1 - L’outil permet de faire ce qu’on appelle du « temps réel » … c'est-à-dire qu’on a la possibilité de recharger le cube en mémoire toutes les secondes.
Inconvénient : Comme pour tous les outils, en fonction du volume de données à traiter, cela peut prendre jusqu’à plusieurs dizaine de minutes. Cette est à mon avis une hérésie.


2 – Fonction Merge :
C’est le seul outil à ma connaissance à proposer de faire la mise en cache en mode incrémentale. Pour ceux qui auraient une version d’évaluation début 2011, cela n’existait pas !!! Ce sont les seuls à ma connaissance à pouvoir le faire. Je parle sous contrôle de monsieur CHAUMAIS.
Avantage : Pour ceux qui ont des problèmes de performances lors des chargements de données, le merge est faite pour vous. Avec cette nouvelle fonction, la possibilité de pseudo temps réelle pourrait avoir du sens, tout dépend du recalcul souhaité en mémoire.

Point 3 – La cartographie
L’outil gère des vraies cartes vectorielles., exportable sous ppt non pas sous forme d’image, mais sous forme de vecteur.
On peut donc la retravailler dans ppt. Un optimiseur de conversion permet d’afficher les cartes rapidement dans ppt ou ppt contrairement à ce que j’ai vu des concurrents.

Point 4 – La mobilité
Grand sujet actuellement.
Ce qui m’a attiré l’attention, c’est que j’ai cru au début que les graphs étaient en flash qui est courant dans ce type d’outil, si l’on veut avoir des graphiques « sexy ». Or ce n’est pas le cas !!! c’est du développement maison, sans plug in !! du full Web !!! Là on certaines sociétés clientes sont réticentes à faire du déploiement sur mobile à cause des failles de sécurité de flash, eux « passent » car sont full Web.

Autre point que j’ai trouvé intéressant, même si j’y vois une utilisation détournée, c’est que la mobilité est non seulement porté sur la visualisation des graphiques, mais ils ont aussi un module audio entièrement paramétrable. A la base utilisé pour pouvoir entendre des chiffres en voiture, c’est une fonctionnalité qui pourrait être utilisée pour les manager ou autre consommateur de chiffres qui seraient à déficience visuelle.

Point 5 – Antoine BUAT
Chez certains clients le produit le plus adapté sera peut être Qlikview, le dashboard de BO ou de Cognos … ou encore DigDash. Monsieur BUAT semble être une personne humble qui n’a pas la prétention d’être meilleur que Qlikview ou que ses concurrent, et son équipe est passionnée.
L’outil me parait bien, malgré encore quelques défauts de jeunesse.

Ils méritent qu’on leur donne une chance de se faire connaître ou de moins d’être benché lors de la mise en place de POC. Bien qu'ayant une page web modeste, avec certainement un traffic modeste, je n'ai pas hésitez à les mettre pour leur faire de la "pub" car cela nous promet de belles batailles dans les POCs à venir !!

Si cela intéresse je propose:
- de faire un article technique un peu plus complet pour les «passionnés» du décisionnel, restreint aux tests que j’ai pu faire.
- de mettre à disposition via le web le prototype que j’ai pu faire (sous couvert d’acceptation de DigDash)
- de vous proposer une interview (au même format que celui de monsieur Nieuwbourg : cv de la boite, etc …) de monsieur BUAT, PDG de digdash que j’ai eu l’occasion de rencontrer, et qui vous permettra de vous faire une première idée de la personne.

A bon entendeur,

Stéphane THIA

13.Posté par SAAL le 26/04/2011 14:19
Bonjour,

Déjà que Qlikview on a du mal a le positionner dans les grands groupes...
Arrêtons de benchmarker les nouvelles solutions qui sortent en les mettant toutes sur le même niveau...Les bons critères doivent être l'innovation technologique, et la satisfaction client, et Qlikview a su depuis 5 ans proposé un modèle nouveau (associatif) non structuré et donc innovant par rapport au modèle OLAP tout en captant de nombreux clients...pour la partie graphique c'est important mais pas essentiel,dans les grands groupes, ce qui interesse les métiers, les daf, les contrôleurs de gestion, c'est la qualité de données, la robustesse des calculs, la compléxité des règles métiers et leur paramètrage, l'intégration de données, le monitoring , le workflow...
Les ex-salariés de BO, SAS, cognos, débarqués, devraient plutot que d'aller systèmatiquement créer leur propre solution de BI sans doute rentable (peut être aussi grâce aux aides en matière d'"innovations"), se demander jusqu'à quand ce modèle le sera... En tout cas, je ne connais pas digdash, mais le contexte de la boite (aprés avoir fait un tour sur le site), ne peut être mis en perspective, de qlikview - quel que soit le cursus des fondateurs. J'ai été un défenseur de l'open source, justement parce que je pense, que la BI est faite principalement de la compréhension d'une problèmatique client, et pas autant liée à la technique (en dehors du sacro-saint "Star schema"), l'open source permettait de s'affranchir de la techno (basé sur des standards) pour se concentrer sur la substantifique moelle : les kpi's, que faire dire aux données, pour quelles actions, comment améliorer les processus opérationnelles...


12.Posté par Jean-Marc Dupont le 15/04/2011 17:56
Twitter
@rchaumais : très bonne, cette idée de "coding party"
une base "ERP" en entrée, une liste d'indicateurs, d'objectifs et de tableaux de bord à produire (il y aura des maquettes à préparer ...)
La beauté n'étant pas pour moi le facteur principal mais plutôt la "usability" (ergonomie, simplicité, capacité à prendre la bonne décision, accessibilité sur toux types de terminaux mobiles, ...)

11.Posté par Jean-Marc Dupont le 15/04/2011 16:58
Twitter
@rchaumais :
Je ne peux pas modifier l'article, c'est M. Nieuwbourg qui s'est chargé de le publier .
Je ne vais donc pas commenter point par point les "erreurs" relevées car serait un peu long.
Mais je laisse les lecteurs juges de décider qui prend le plus parti pour un outil ou l'autre dans nos 2 contributions. Je serais curieux de lire les résultats.

10.Posté par rchaumais le 15/04/2011 16:54
Twitter
Ysance prête les locaux pour cette première BI Coding Partie à Paris :-)

9.Posté par rchaumais le 15/04/2011 16:52
Twitter
Merci pour ces précisions.

Je pense qu'il serai assez sympa que nous organisions des Coding Parties sur ces outils de nouvelles générations en BI. On se retrouve tous le temps d'une journée ou d'une soirée dans un endroit sympa, chacun avec sa solution "fétiche".

On se prend une bonne source de données pour un projet BI bien trapu et on partage notre passion pour le décisionnel en essayant de développer la plus belle application de dashboarding et d'analyse possible. Cela peut être vraiment enrichissant.

Je mettrai bien dans la place DigDash, Tableau, Prelytis, ReportOne, GoodData, PivotTable, QlikView. Si vous en voyez d'autre, la porte est grande ouverte.

Qu'en pensez-vous ? Des volontaires ?

8.Posté par Jean-Marc Dupont le 15/04/2011 16:41
Twitter
Encore une fois, je suis factuel, pas orienté vers un outil ou l'autre.

J'ai parlé rapidement du modèle associatif dans la partie "Modèle de données" mais sans m'y attarder c'est vrai (souci de ne pas faire trop long).

Les 2 outils sont "in memory", avec cependant une différence :
- Digdash répartit les données entre la mémoire du serveur et la mémoire du client web, en fonction du volume de données à afficher, ce qui a l'avantage d'éviter des allers-retours client/serveur sur le réseau lorsqu'il n'y a pas trop de données (c'est le client web qui traite les données sur le poste de l'utilisateur)
- Qlikview charge l'ensemble des données sur la mémoire du serveur (ou sur le poste client si l'on n'est pas en configuration client/serveur)

Concernant le stockage, Digdash et Qlikview fonctionnent là encore de la même manière : ils vont chercher les données source (partie "alimentation") et les stockent dans un fichier propriétaire puis les envoient vers la mémoire.
Digdash n'est pas pas plus un outil de restitution que ne l'est Qlikview.

1 2
Nouveau commentaire :
Facebook Twitter

Vous pouvez commenter ou apporter un complément d’information à tous les articles de ce site. Les commentaires sont libres et ouverts à tous. Néanmoins, nous nous réservons le droit de supprimer, sans explication ni préavis, tout commentaire qui ne serait pas conforme à nos règles internes de fonctionnement, c'est-à-dire tout commentaire diffamatoire ou sans rapport avec le sujet de l’article. Par ailleurs, les commentaires anonymes sont systématiquement supprimés s’ils sont trop négatifs ou trop positifs. Ayez des opinions, partagez les avec les autres, mais assumez les ! Merci d’avance. Merci de noter également que les commentaires ne sont pas automatiquement envoyés aux rédacteurs de chaque article. Si vous souhaitez poser une question au rédacteur d'un article, contactez-le directement, n'utilisez pas les commentaires.