Un Cube, qu'est ce que c'est ?

helios a présenté l'énoncé suivant :

Alain Montfranc a écrit :

helios avait quoté comme un goret asthmatique en rut le 03/10/2011 :

XML qui fait du multiniveaux par balise (ce qui explique que les
moulinettes XML-SQL soit du pipeau

<TROLL>

Encore une affirmation gratuite (et fausse)

aussi faux que la "perpective cavaliere" represente un volume sur une
feuille de papier d'ailleurs la perpective cavaliere est tellement parfaite
que les camera en 3D n'existent pas et les hologrammes non plus

Comparaison n'est pas raison

d'ailleurs l'artifice "perpective cavaliere" ne permet pas de representer un
hypercube

on s'en fout

XML est multi niveau de donnés SQL à 2 niveaux de donnée (plan) alors
demontre moi que tu peut representer par exemple un objet a 10 dimensions sur
une feuille de papier exemple dessinne sur un format A4 un objet ayant les
dimensions Q R S T U V W X Y Z de 30 mm

Aucun rapport

</TROLL>

Alain Montfranc a écrit :

helios a présenté l'énoncé suivant :

Alain Montfranc a écrit :

helios avait quoté comme un goret asthmatique en rut le 03/10/2011 :

XML qui fait du multiniveaux par balise (ce qui explique que les
moulinettes XML-SQL soit du pipeau

<TROLL>

Encore une affirmation gratuite (et fausse)

aussi faux que la "perpective cavaliere" represente un volume sur
une feuille de papier d'ailleurs la perpective cavaliere est
tellement parfaite que les camera en 3D n'existent pas et les
hologrammes non plus

Comparaison n'est pas raison

d'ailleurs l'artifice "perpective cavaliere" ne permet pas de
representer un hypercube

on s'en fout

XML est multi niveau de donnés SQL à 2 niveaux de donnée (plan)
alors demontre moi que tu peut representer par exemple un objet a 10
dimensions sur une feuille de papier exemple dessinne sur un format
A4 un objet ayant les dimensions Q R S T U V W X Y Z de 30 mm

Aucun rapport

puisques Alain Montfranc le dit la réalité est comme cela, malgrés que
sa moulinette n'a pas ete capable de convertir une table XML que j'avais
fournis (127 balises imbriqué) la comparaison objet multidimesinnel
feuille est juste et demontre bien que une table SQL ne peux pas etre
l'equivalent d'une table XML si celle ci a un nombre de balises imbriqué
suffisament grand

Alain Montfranc a peut etre des interets a pretendre le contraire style
vente a des gogos de sa moulinette

</TROLL>

helios a écrit le 04/10/2011 à 07h21 :

Alain Montfranc a écrit :

helios a présenté l'énoncé suivant :

Alain Montfranc a écrit :

helios avait quoté comme un goret asthmatique en rut le 03/10/2011 :

XML qui fait du multiniveaux par balise (ce qui explique que les
moulinettes XML-SQL soit du pipeau

<TROLL>

Encore une affirmation gratuite (et fausse)

aussi faux que la "perpective cavaliere" represente un volume sur
une feuille de papier d'ailleurs la perpective cavaliere est
tellement parfaite que les camera en 3D n'existent pas et les
hologrammes non plus

Comparaison n'est pas raison

d'ailleurs l'artifice "perpective cavaliere" ne permet pas de
representer un hypercube

on s'en fout

XML est multi niveau de donnés SQL à 2 niveaux de
donnée (plan)
alors demontre moi que tu peut representer par exemple un objet a 10
dimensions sur une feuille de papier exemple dessinne sur un format
A4 un objet ayant les dimensions Q R S T U V W X Y Z de 30 mm

Aucun rapport

puisques Alain Montfranc le dit la réalité est comme cela,
malgrés que
sa moulinette n'a pas ete capable de convertir une table XML que j'avais
fournis (127 balises imbriqué) la comparaison objet multidimesinnel
feuille est juste et demontre bien que une table SQL ne peux pas etre
l'equivalent d'une table XML si celle ci a un nombre de balises imbriqué
suffisament grand

Alain Montfranc a peut etre des interets a pretendre le contraire style
vente a des gogos de sa moulinette

</TROLL>

bonjour à tous,
bonjour Helios,

loin de moi l'intention d'entretenir la polémique. Je cherche juste à comprendre, et suis néophyte en la matière.

Pouvez vous expliquer ce que vous entendez par "perspective cavalière" ?
j'ai vu la représentation d'un cube sur wikipedia, et franchement, je ne vois pas comment une représentation telle qu'elle est faite sur wikipedia est réalisable et analysable par un opérationnel métier.

en revanche, avoir un tableau 2D avec en abcisses des dimensions et en ordonnées des axes d'analyses : jusque là je vois.
Ajouter des "filtres" ou "segments" (pour coller à la terminologie ?), pour recalculer les mesures, ça aussi je vois.
Permettre la visualisation des mesures selon une granularité plus ou moins fine : ça aussi je vois.
et enfin, pivoter l'information pour qu'un axe d'analyse devienne une dimension : ça aussi je vois.

Qu'est ce que je ne vois donc pas que vous exprimez dans vos posts ?
et encore une fois, qu'est ce que les solutions sur le marché me proposent que je ne fais pas là ?

merci encore pour vos explications.
à bientôt

thanksforyourhelp a écrit :

bonjour à tous,
bonjour Helios,

loin de moi l'intention d'entretenir la polémique. Je cherche juste à
comprendre, et suis néophyte en la matière.

Pouvez vous expliquer ce que vous entendez par "perspective cavalière" ?
j'ai vu la représentation d'un cube sur wikipedia, et franchement, je ne vois
pas comment une représentation telle qu'elle est faite sur wikipedia est
réalisable et analysable par un opérationnel métier.

http://fr.wikipedia.org/wiki/Perspective_cavali%C3%A8re

c'est en dessin industriel une maniere de representer un volume sur un
plan (feuille)

en revanche, avoir un tableau 2D avec en abcisses des dimensions et en
ordonnées des axes d'analyses : jusque là je vois.
Ajouter des "filtres" ou "segments" (pour coller à la terminologie ?), pour
recalculer les mesures, ça aussi je vois.
Permettre la visualisation des mesures selon une granularité plus ou moins fine
: ça aussi je vois.
et enfin, pivoter l'information pour qu'un axe d'analyse devienne une dimension
: ça aussi je vois.

Qu'est ce que je ne vois donc pas que vous exprimez dans vos posts ?
et encore une fois, qu'est ce que les solutions sur le marché me proposent que
je ne fais pas là ?

un SGBD à multi niveau de donnée sait gere plus de deux dimension (les
systeme apparenté PICK ou multivalué le font par multivaleur, Caché le
fait par multidimensionnel, et XML le fait par balise)

si tu structure ta base en XML tu prend un sgbd qui gere XML
si tu fait du multidimensionnel tu prends caché
si tu structure en multivaleur tu prend un apparenté PICK

exemple en XML pour un "cube"

<x1>
data
<y1>
data
</y1>
<ym>
data
<z1>
data
</z1>
<zp>
data
</zp>
</ym>
<ym>
<z1>
data
</z1>
</ym>
</x1>
<xn>


</xn>

en fait tu n X m Y p Z avec n , m, p compris entre 0 et la limite du
SGBD pour qu'une moulinette XML vers SQL puisse convertir UNE table XML
en UNE table SQL il faut que n, m, et P soit 0 ou 1 (deux valeurs)

merci encore pour vos explications.
à bientôt

thanksforyourhelp a écrit :

Yliur a écrit le 03/10/2011 à 23h37 :

Le Mon, 03 Oct 2011 15:59:39 -0500
thanksforyourhelp a écrit :

Pif 34 a écrit le 03/10/2011 à 22h17 :

Alain Montfranc wrote:

helios avait quoté comme un goret asthmatique en rut le
03/10/2011 :

XML qui fait du multiniveaux par balise (ce qui explique que les
moulinettes XML-SQL soit du pipeau

Encore une affirmation gratuite (et fausse)

depuis 3 ans le meme combat.... vivement la retraite (pas la
mienne) !

en effet ... je m'aperçois que ma question a provoqué un ...
dérangement (peut on le dire ainsi ?).

j'avais de nouvelles questions, mais je crains devoir m'arrêter
là
pour des raisons de santé publique.

Merci à tous. Je vais suivre ma quête...

Clique plutôt sur "Ignorer les remous" et pose tes questions.
S'il faut
s'arrêter de marcher à chaque troll qui passe, où va-t-on ?

merci Yliur,
alors voilà...
j'ai bien lu attentivement l'article sur Wikipedia et bien retenu les
définitions.

Je rapatrie sur access une table de toutes les transactions qui sont passés
dans l'enseigne dans laquelle je travaille.

quel enseigne ou quel produits ?

helios a écrit le 04/10/2011 à 11h40 :

thanksforyourhelp a écrit :

bonjour à tous,
bonjour Helios,

loin de moi l'intention d'entretenir la polémique. Je cherche juste
à
comprendre, et suis néophyte en la matière.

Pouvez vous expliquer ce que vous entendez par "perspective
cavalière" ?
j'ai vu la représentation d'un cube sur wikipedia, et franchement, je
ne vois
pas comment une représentation telle qu'elle est faite sur wikipedia
est
réalisable et analysable par un opérationnel métier.

http://fr.wikipedia.org/wiki/Perspective_cavali%C3%A8re

c'est en dessin industriel une maniere de representer un volume sur un
plan (feuille)

en revanche, avoir un tableau 2D avec en abcisses des dimensions et en
ordonnées des axes d'analyses : jusque là je vois.
Ajouter des "filtres" ou "segments" (pour coller à
la terminologie ?), pour
recalculer les mesures, ça aussi je vois.
Permettre la visualisation des mesures selon une granularité plus ou
moins fine
: ça aussi je vois.
et enfin, pivoter l'information pour qu'un axe d'analyse devienne une
dimension
: ça aussi je vois.

Qu'est ce que je ne vois donc pas que vous exprimez dans vos posts ?
et encore une fois, qu'est ce que les solutions sur le marché me
proposent que
je ne fais pas là ?

un SGBD à multi niveau de donnée sait gere plus de deux dimension
(les
systeme apparenté PICK ou multivalué le font par multivaleur,
Caché le
fait par multidimensionnel, et XML le fait par balise)

si tu structure ta base en XML tu prend un sgbd qui gere XML
si tu fait du multidimensionnel tu prends caché
si tu structure en multivaleur tu prend un apparenté PICK

exemple en XML pour un "cube"

<x1>
data
<y1>
data
</y1>
<ym>
data
<z1>
data
</z1>
<zp>
data
</zp>
</ym>
<ym>
<z1>
data
</z1>
</ym>
</x1>
<xn>


</xn>

en fait tu n X m Y p Z avec n , m, p compris entre 0 et la limite du
SGBD pour qu'une moulinette XML vers SQL puisse convertir UNE table XML
en UNE table SQL il faut que n, m, et P soit 0 ou 1 (deux valeurs)

merci encore pour vos explications.
à bientôt

merci Hélios pour cette explication.
j'ai lu un bon article de vulgarisation sur l'architecture Caché à cette adresse :
http://www.intersystems.fr/page/fr/vue_synthetique_cache.html

maintenant, comme vous le dites, un cube est une représentation d'un volume sur un espace plan. c'est une définition qui me convient quand il s'agit de regarder non plus la représentation géométrique ni la méthode de construction, mais les données et les mesures que le cube contient et la lecture que je vais en faire.

Car, "at the end of the day", les opérationnels attendent d'un cube de pouvoir analyser ces chiffres, de descendre et de remonter la granularité des chiffres, de faire pivoter les dimensions et les axes afin de prendre des décisions stratégiques et économiques sur les actions à venir.

En quoi le fait qu'il y ait derrière ce cube une base en XML ou SQL change t'il la donne ?
Est ce le volume des données et la vitesse des calculs qui vont déterminer les choix de langage et de structure de la base de données ?
et dans ce cas, en quoi le cube, s'il n'est qu'une représentation, influe t'il sur le choix de ce SGBDR ou M ?
merci encore pour votre temps

thanksforyourhelp a écrit :

helios a écrit le 04/10/2011 à 11h40 :

thanksforyourhelp a écrit :

bonjour à tous,
bonjour Helios,

loin de moi l'intention d'entretenir la polémique. Je cherche juste
à
comprendre, et suis néophyte en la matière.

Pouvez vous expliquer ce que vous entendez par "perspective
cavalière" ?
j'ai vu la représentation d'un cube sur wikipedia, et franchement, je
ne vois
pas comment une représentation telle qu'elle est faite sur wikipedia
est
réalisable et analysable par un opérationnel métier.

http://fr.wikipedia.org/wiki/Perspective_cavali%C3%A8re

c'est en dessin industriel une maniere de representer un volume sur un
plan (feuille)

en revanche, avoir un tableau 2D avec en abcisses des dimensions et en
ordonnées des axes d'analyses : jusque là je vois.
Ajouter des "filtres" ou "segments" (pour coller à
la terminologie ?), pour
recalculer les mesures, ça aussi je vois.
Permettre la visualisation des mesures selon une granularité plus ou
moins fine
: ça aussi je vois.
et enfin, pivoter l'information pour qu'un axe d'analyse devienne une
dimension
: ça aussi je vois.

Qu'est ce que je ne vois donc pas que vous exprimez dans vos posts ?
et encore une fois, qu'est ce que les solutions sur le marché me
proposent que
je ne fais pas là ?

un SGBD à multi niveau de donnée sait gere plus de deux dimension
(les
systeme apparenté PICK ou multivalué le font par multivaleur,
Caché le
fait par multidimensionnel, et XML le fait par balise)

si tu structure ta base en XML tu prend un sgbd qui gere XML
si tu fait du multidimensionnel tu prends caché
si tu structure en multivaleur tu prend un apparenté PICK

exemple en XML pour un "cube"

<x1>
data
<y1>
data
</y1>
<ym>
data
<z1>
data
</z1>
<zp>
data
</zp>
</ym>
<ym>
<z1>
data
</z1>
</ym>
</x1>
<xn>


</xn>

en fait tu n X m Y p Z avec n , m, p compris entre 0 et la limite du
SGBD pour qu'une moulinette XML vers SQL puisse convertir UNE table XML
en UNE table SQL il faut que n, m, et P soit 0 ou 1 (deux valeurs)

merci encore pour vos explications.
à bientôt

merci Hélios pour cette explication.
j'ai lu un bon article de vulgarisation sur l'architecture Caché à cette
adresse :
http://www.intersystems.fr/page/fr/vue_synthetique_cache.html

maintenant, comme vous le dites, un cube est une représentation d'un volume sur
un espace plan. c'est une définition qui me convient quand il s'agit de regarder
non plus la représentation géométrique ni la méthode de construction, mais les
données et les mesures que le cube contient et la lecture que je vais en faire.


Car, "at the end of the day", les opérationnels attendent d'un cube de pouvoir
analyser ces chiffres, de descendre et de remonter la granularité des chiffres,
de faire pivoter les dimensions et les axes afin de prendre des décisions
stratégiques et économiques sur les actions à venir.

En quoi le fait qu'il y ait derrière ce cube une base en XML ou SQL change t'il
la donne ?

simplement que SQL ne sait pas gerer plus de deux dimensions donc
incapable de gere ton cube puisque 3 dimensions
apres a coup d'artifice on peut gerer en SQL un cube mais cela revient a
gerer un solide comme sa representation en perpective cavalier sur une
feuille comme expliqué dans WP la perpertive cavaliere provoque des
degradation et incoherences
et bien SQL gerant un cube c'est pareil c'est des degradations et des
incoherences en gros

Est ce le volume des données et la vitesse des calculs qui vont déterminer les
choix de langage et de structure de la base de données ?

pour des petits volumes de données sur un gros calculateur les
"bricolages" SQL sont suffisant

un system MV sur un 486 avec un disque IDE à ete remplacer pour garder
les meme performance avec SQL par un IBM multi pross RAID6 à 1Meuro
voila pour donner une idée du ratio performance
en 2002 FT a demandé à Oracle de remplacer sa base de donnée 42C sous
PICK-UNIVERSE d'IBM resultat oracle renvoyé a ses etudes

et dans ce cas, en quoi le cube, s'il n'est qu'une représentation, influe t'il
sur le choix de ce SGBDR ou M ?
merci encore pour votre temps

le cube n'est pas une representation mais la structure de la base en 3
dimensions (l'hyper cube est à 4 dimensions ....)

ton cube en SQL est gere face par face et des jointures font les
raccords entre les faces alors qu'un SGBD qui gere XML ou le
dimentionnel ou le MV gere ton cube en tant objet a 3 dimensions ce qui
est totalement different

en realité il ne s'agit pas de cube mais d'objet a 3 dimensions ce qui
fait que l'objet peux avoir bien plus que 6 faces

en raccourcis
SQL gere des surfaces et fait des jointures entre surface pour gerer les
volumes , les hyper-cubes ......
les sgbd XML MV et MD geres des objets ayant de nombreuses dimensions en
tant qu'objet '3 dim cube , 4dim hyper cube .....les MV vont jusque que
127 DIM eyt les MD et XML no limite mais en pratique a ce jour aucune
base reel n'a depasse 10 dim)

helios a écrit le 04/10/2011 à 16h43 :

thanksforyourhelp a écrit :

helios a écrit le 04/10/2011 à 11h40 :

thanksforyourhelp a écrit :

bonjour à tous,
bonjour Helios,

loin de moi l'intention d'entretenir la polémique. Je cherche juste
à
comprendre, et suis néophyte en la matière.

Pouvez vous expliquer ce que vous entendez par "perspective
cavalière" ?
j'ai vu la représentation d'un cube sur wikipedia, et franchement, je
ne vois
pas comment une représentation telle qu'elle est faite sur wikipedia
est
réalisable et analysable par un opérationnel métier.

http://fr.wikipedia.org/wiki/Perspective_cavali%C3%A8re

c'est en dessin industriel une maniere de representer un volume sur un
plan (feuille)

en revanche, avoir un tableau 2D avec en abcisses des dimensions et en
ordonnées des axes d'analyses : jusque là je vois.
Ajouter des "filtres" ou "segments" (pour coller
à
la terminologie ?), pour
recalculer les mesures, ça aussi je vois.
Permettre la visualisation des mesures selon une granularité plus ou
moins fine
: ça aussi je vois.
et enfin, pivoter l'information pour qu'un axe d'analyse devienne une
dimension
: ça aussi je vois.

Qu'est ce que je ne vois donc pas que vous exprimez dans vos posts ?
et encore une fois, qu'est ce que les solutions sur le marché me
proposent que
je ne fais pas là ?

un SGBD à multi niveau de donnée sait gere plus de deux
dimension
(les
systeme apparenté PICK ou multivalué le font par multivaleur,
Caché le
fait par multidimensionnel, et XML le fait par balise)

si tu structure ta base en XML tu prend un sgbd qui gere XML
si tu fait du multidimensionnel tu prends caché
si tu structure en multivaleur tu prend un apparenté PICK

exemple en XML pour un "cube"

<x1>
data
<y1>
data
</y1>
<ym>
data
<z1>
data
</z1>
<zp>
data
</zp>
</ym>
<ym>
<z1>
data
</z1>
</ym>
</x1>
<xn>


</xn>

en fait tu n X m Y p Z avec n , m, p compris entre 0 et la limite du
SGBD pour qu'une moulinette XML vers SQL puisse convertir UNE table XML
en UNE table SQL il faut que n, m, et P soit 0 ou 1 (deux valeurs)

merci encore pour vos explications.
à bientôt

merci Hélios pour cette explication.
j'ai lu un bon article de vulgarisation sur l'architecture Caché
à cette
adresse :
http://www.intersystems.fr/page/fr/vue_synthetique_cache.html

maintenant, comme vous le dites, un cube est une représentation d'un
volume sur
un espace plan. c'est une définition qui me convient quand il s'agit de
regarder
non plus la représentation géométrique ni la
méthode de construction, mais les
données et les mesures que le cube contient et la lecture que je vais
en faire.


Car, "at the end of the day", les opérationnels attendent
d'un cube de pouvoir
analyser ces chiffres, de descendre et de remonter la granularité des
chiffres,
de faire pivoter les dimensions et les axes afin de prendre des
décisions
stratégiques et économiques sur les actions à venir.

En quoi le fait qu'il y ait derrière ce cube une base en XML ou SQL
change t'il
la donne ?

simplement que SQL ne sait pas gerer plus de deux dimensions donc
incapable de gere ton cube puisque 3 dimensions
apres a coup d'artifice on peut gerer en SQL un cube mais cela revient a
gerer un solide comme sa representation en perpective cavalier sur une
feuille comme expliqué dans WP la perpertive cavaliere provoque des
degradation et incoherences
et bien SQL gerant un cube c'est pareil c'est des degradations et des
incoherences en gros

Est ce le volume des données et la vitesse des calculs qui vont
déterminer les
choix de langage et de structure de la base de données ?

pour des petits volumes de données sur un gros calculateur les
"bricolages" SQL sont suffisant

un system MV sur un 486 avec un disque IDE à ete remplacer pour garder
les meme performance avec SQL par un IBM multi pross RAID6 à 1Meuro
voila pour donner une idée du ratio performance
en 2002 FT a demandé à Oracle de remplacer sa base de
donnée 42C sous
PICK-UNIVERSE d'IBM resultat oracle renvoyé a ses etudes

et dans ce cas, en quoi le cube, s'il n'est qu'une représentation,
influe t'il
sur le choix de ce SGBDR ou M ?
merci encore pour votre temps

le cube n'est pas une representation mais la structure de la base en 3
dimensions (l'hyper cube est à 4 dimensions ....)

ton cube en SQL est gere face par face et des jointures font les
raccords entre les faces alors qu'un SGBD qui gere XML ou le
dimentionnel ou le MV gere ton cube en tant objet a 3 dimensions ce qui
est totalement different

en realité il ne s'agit pas de cube mais d'objet a 3 dimensions ce qui
fait que l'objet peux avoir bien plus que 6 faces

en raccourcis
SQL gere des surfaces et fait des jointures entre surface pour gerer les
volumes , les hyper-cubes ......
les sgbd XML MV et MD geres des objets ayant de nombreuses dimensions en
tant qu'objet '3 dim cube , 4dim hyper cube .....les MV vont jusque que
127 DIM eyt les MD et XML no limite mais en pratique a ce jour aucune
base reel n'a depasse 10 dim)

super Hélios, je commence à percevoir la nature du cube : on est bien dans l'univers de la BDD et non plus dans sa représentation.

est ce que ça signifie que je dois définir en amont les axes d'analyse, les dimensions et les mesures afin que le SGBDM les prévoit ou est ce que j'ai, en tant qu'utilisateur final, la possibilité de définir des dimensions et des axes en live ?

Autre question : si c'est le SGBDM qui fabrique le cube, à quoi servent alors les outils de BI tels que Saas, R, XnView et autres ... ?

merci pour vos lumières !!

puis-je moi aussi poser la question d'ou tu veux en venir ?

que tu utilise un cube ou pas, tout le monde s'en moque, et toi aussi
normalement (c'est pas agressif, c'est provocateur). Qu'importe le nom...

TCD c'est une fonction excel et peut etre access... on quitte le monde
de la base de donnée relationnelle car il ne s'agit pas d'un opérateur
relationnel a proprement parler.

Un cume, un espace multidimensionnel, des composantes multimodales, tu
peux donner des nom, c'est pas le plus important..

Un cube ca induit plusieurs choses comme le fait justement remarque Yliur:
1) un outillage générique adapté à de gros volume (datawarehouse,
datamart), des outils d'ETL, des outils d'analyse et de visu, etc.
2 (le plus important) l'usage : un (hyper)cube c'est un espace
muldimensionnel pour lequel on veut extraire et analyser une ou
plusieurs dimensions. Une dimension, c'est simple et pas besoin d'outil.
Plus de 2 dimensions, c'est complexe à visualiser et analyser en
général, ca implique des outils d'analyse de données et de visu d'info
fouillé et adapté au domaine. Reste les 2D: on va extraire un plan dans
ton espace qu'on va analyser. Ce que te permet le cube, c'est de choisir
indifférement 2 dimensions et de pouvoir les comparer...

un datadube, en relationnel c'est quoi ?
deux entités:
- entité "dimension"
- entité "point"

et une relation n-n entre les deux, avec un attribut "valeur" qui donc
permet d'associer à chaque point dans chaque dimension une valeur.


et sortir un plan, c'est projeter sur un plan en Y une dimension et en X
une autre... c'est tout

sortir 3D ou plus, c'est facile aussi... c'est analyser qui est sur...

On peut biensur enrober sur ce pattern, mais un datacube, c'est ni plus
ni moins que ca...

Donc le datacube, c'est un mot qui t'intéresse quand tu veux vendre ou
acheter un produit par rapport à une catégorie de distribution de
software pasque t'auras le Oracle Grid, le oracle cube par exemple etc.
avec son lot d'outillage et le prix qui va bien..

Ce qui me semble intéressant, c'est pas tant de produire un datacube que
de produires les outils pertinent pour l'utilisateur final... car ce qui
est proposé est le plus souvent assez pipo et inutilisable... y'a plein
d'outils matheux mal compris et mal utilisé, et aucun outils visuel...

helios a écrit :

Alain Montfranc a écrit :

helios a présenté l'énoncé suivant :

Alain Montfranc a écrit :

helios avait quoté comme un goret asthmatique en rut le 03/10/2011 :

XML qui fait du multiniveaux par balise (ce qui explique que les
moulinettes XML-SQL soit du pipeau

<TROLL>

Encore une affirmation gratuite (et fausse)

aussi faux que la "perpective cavaliere" represente un volume sur une
feuille de papier d'ailleurs la perpective cavaliere est tellement
parfaite que les camera en 3D n'existent pas et les hologrammes non plus

Comparaison n'est pas raison

d'ailleurs l'artifice "perpective cavaliere" ne permet pas de representer
un hypercube

on s'en fout

XML est multi niveau de donnés SQL à 2 niveaux de donnée (plan) alors
demontre moi que tu peut representer par exemple un objet a 10 dimensions
sur une feuille de papier exemple dessinne sur un format A4 un objet
ayant les dimensions Q R S T U V W X Y Z de 30 mm

Aucun rapport

puisques Alain Montfranc le dit la réalité est comme cela, malgrés que sa
moulinette n'a pas ete capable de convertir une table XML que j'avais fournis
(127 balises imbriqué) la comparaison objet multidimesinnel feuille est juste
et demontre bien que une table SQL ne peux pas etre l'equivalent d'une table
XML si celle ci a un nombre de balises imbriqué suffisament grand

Dans tes reves. Ma moulinette marche tres bien ;-)

Alain Montfranc a peut etre des interets a pretendre le contraire style vente
a des gogos de sa moulinette

Je ne vends rien. Contrairement à d'autres

</TROLL>