Tu pretends avoir un fichier de test de 200 Mo qui ferait echouer ma
moulinette. Merci de le communiquer ou de communiquer un moyen de le
générer (dans un langage comme C ou shell svp).
je te l'ai donner dans en basic qui est le language le plus distribue au
monde (1 exemplaire dans chaque systeme microsoft depuis 1981 mSDOS a WINDOWS
VISTA)
a toi de convertir dans le language de ton choix mais pour moi le C etant
moins performant que le databasic des SGBDRMV je n'ai pas perdu de temp a
l'apprendre (il a exister un compilateur C sous SGBDRMV donc le seul
utilisateur a ete la boite qui l'avait produit)Une fois le fichier en ma possession je publierai les resultats de manière
objective.
je t ai detaille la structure precise dans le post suivant alors fait toi un
fichier test repondant si tu veux pas utilise la routine basic pour le creer
Tu pretends avoir un fichier de test de 200 Mo qui ferait echouer ma
moulinette. Merci de le communiquer ou de communiquer un moyen de le
générer (dans un langage comme C ou shell svp).
je te l'ai donner dans en basic qui est le language le plus distribue au
monde (1 exemplaire dans chaque systeme microsoft depuis 1981 mSDOS a WINDOWS
VISTA)
a toi de convertir dans le language de ton choix mais pour moi le C etant
moins performant que le databasic des SGBDRMV je n'ai pas perdu de temp a
l'apprendre (il a exister un compilateur C sous SGBDRMV donc le seul
utilisateur a ete la boite qui l'avait produit)
Une fois le fichier en ma possession je publierai les resultats de manière
objective.
je t ai detaille la structure precise dans le post suivant alors fait toi un
fichier test repondant si tu veux pas utilise la routine basic pour le creer
Tu pretends avoir un fichier de test de 200 Mo qui ferait echouer ma
moulinette. Merci de le communiquer ou de communiquer un moyen de le
générer (dans un langage comme C ou shell svp).
je te l'ai donner dans en basic qui est le language le plus distribue au
monde (1 exemplaire dans chaque systeme microsoft depuis 1981 mSDOS a WINDOWS
VISTA)
a toi de convertir dans le language de ton choix mais pour moi le C etant
moins performant que le databasic des SGBDRMV je n'ai pas perdu de temp a
l'apprendre (il a exister un compilateur C sous SGBDRMV donc le seul
utilisateur a ete la boite qui l'avait produit)Une fois le fichier en ma possession je publierai les resultats de manière
objective.
je t ai detaille la structure precise dans le post suivant alors fait toi un
fichier test repondant si tu veux pas utilise la routine basic pour le creer
je reformules
le fichier epasqy.xml
contient 15000 occurrences
chaque occurrence contient entre 1 et 64 sous occurrence
chaque sous occurrence contient entre 1 et 360 sous sous occurrence
chaque sous sous occurrence contient entre 1 et 64 sous sous sous occurrence
et une des occurrences a 64 sous occurrences ddonc une qui contient 360 sous
sous occurrence donc une contient 64 sous sous sous occurrences
ce qui en structure mono value
oblige a créer une table de 15000 ligne pointant sur 1 a 64 tables chacune
je reformules
le fichier epasqy.xml
contient 15000 occurrences
chaque occurrence contient entre 1 et 64 sous occurrence
chaque sous occurrence contient entre 1 et 360 sous sous occurrence
chaque sous sous occurrence contient entre 1 et 64 sous sous sous occurrence
et une des occurrences a 64 sous occurrences ddonc une qui contient 360 sous
sous occurrence donc une contient 64 sous sous sous occurrences
ce qui en structure mono value
oblige a créer une table de 15000 ligne pointant sur 1 a 64 tables chacune
je reformules
le fichier epasqy.xml
contient 15000 occurrences
chaque occurrence contient entre 1 et 64 sous occurrence
chaque sous occurrence contient entre 1 et 360 sous sous occurrence
chaque sous sous occurrence contient entre 1 et 64 sous sous sous occurrence
et une des occurrences a 64 sous occurrences ddonc une qui contient 360 sous
sous occurrence donc une contient 64 sous sous sous occurrences
ce qui en structure mono value
oblige a créer une table de 15000 ligne pointant sur 1 a 64 tables chacune
helios a écrit :Alain Montfranc a écrit :helios a écritAlain Montfranc a écrit :helios a écritA priori il n'y a pas 1474560 tables dans ton exemple, mais 1
table à 64 lignes liée à une table dont un identifiant correspond
à 360 valeurs (relation 1...360) liée à une table par une
relation 1...64. Je pense que tu confonds valeur et table.
non il y a 15000 item donc un a 64 valeurs donc une a 360 sous
valeur donc une a 64 sous sous valeur
les valeurs sont differente d'un item a l'autre
ce qui donne 1 table de 15000 lignes ......
Ce qui est minuscule :-D
Mais tu parlaius de 17000 tables. Elles sont ou ?
15000 lignes de 64 valeurs qui ont chacune 360 lien et
360 fichiers ayant chacun 64 liens vers 64 fichiers ce qui donne un
total de 15000*64*360*64 tables pour avoir une achitecture type
monovaluéMais j'interprete peut etre mal ton français approximatif, aussi le
un item est ce que tu appelle une ligne
si tu veuxTABLE divisé en item (ligne) divise en valeur (colonne)
si tu veuxdivise en sous valeur
ou en un lien vers une autre table
ce qui fait ici 15000*64 liens vers le meme nombre de tablesdivise en sous sous valeur ......
ou un autre lien
ce qui fait ici 15000*64*360 liens vers le meme nombre de tables puis
ce qui fait ici 15000*64*360*64 liens vers le meme nombre de tablesmeilleur moyen serait que tu donnes un fichier test.
T'as qu'à anonymiser le fichier en question.
un fichier test de 200Mo :-)
Pour info mon fichier de test fait 1,7 Go, alors tes 200 Mo...
Je serai vraiment interssé par un test de ma moulinette. A ce stade
de la discussion je reste persuadé que ton fichier passera sans
probleme. Je ne demande qu'a avoir un jeu de test qui me
permettrait soit de reconnaitre publiquement l'infériorité des SGBD
classique (postgresql en l'occurence), soit...
Mais tu as peut etre peur du resultat ? :-D
cree un fichier xml ayant 15000 occurence contenant chacune 64 sous
ocurence de 360 sous sous occurences de 64 sous sous sous occurences
T'as changé :-)
Là tu as 15000 * 64 * 360 * 64 = 22118400000 valeurs au bout
Ton fichier faisant 200 Mo ca laisse
0,0094814814814814814814814814814815 octet par donnée sans compter la
place prise par les balises XML....
Ta proposition est incohérente avec tes affirmations
Ou alors voulais tu dire (cf. ton premier discours) :
Cree un fichier XML ayant 15000 occurences dont *une* contient 64
sous ocurence dont une contient 360 sous sous occurences dont une
contient 64 sous sous sous occurences
je reformules
le fichier epasqy.xml
contient 15000 occurrences
chaque occurrence contient entre 1 et 64 sous occurrence
chaque sous occurrence contient entre 1 et 360 sous sous occurrence
chaque sous sous occurrence contient entre 1 et 64 sous sous sous
occurrence
et une des occurrences a 64 sous occurrences ddonc une qui contient 360
sous sous occurrence donc une contient 64 sous sous sous occurrences
ce qui en structure mono value
oblige a créer une table de 15000 ligne pointant sur 1 a 64 tables
chacune qui elle même pointe sur 1 a 360 tables chacune qui pointe elle
même sur 1 a 64 tables chacune
admettons que chaque ligne pointe en moyenne sur 6 tables de niveau1
admettons que chaque table de niveau 1 pointe en moyenne sur 36 tables
de niveau2
admettons que chaque table de niveau2 pointe sur 6 table de niveau3
cela donne quand même 15000x6x36x6 table soit 19440000 table a créer
la réalité pour appeler les occurrences par leur nom le fichier EPASQY
contient la liste de 15000 terrains issus du regroupement de 1 a 64 lots
qui étaient constitué de 1 a 360 parcelles qui provenaient de la fusion
de 1 a 64 terrains
alors comment réagi ta moulinette pour transformer ce genre de fichier
xml en base monovalué ? forfait ?
helios a écrit :
Alain Montfranc a écrit :
helios a écrit
Alain Montfranc a écrit :
helios a écrit
A priori il n'y a pas 1474560 tables dans ton exemple, mais 1
table à 64 lignes liée à une table dont un identifiant correspond
à 360 valeurs (relation 1...360) liée à une table par une
relation 1...64. Je pense que tu confonds valeur et table.
non il y a 15000 item donc un a 64 valeurs donc une a 360 sous
valeur donc une a 64 sous sous valeur
les valeurs sont differente d'un item a l'autre
ce qui donne 1 table de 15000 lignes ......
Ce qui est minuscule :-D
Mais tu parlaius de 17000 tables. Elles sont ou ?
15000 lignes de 64 valeurs qui ont chacune 360 lien et
360 fichiers ayant chacun 64 liens vers 64 fichiers ce qui donne un
total de 15000*64*360*64 tables pour avoir une achitecture type
monovalué
Mais j'interprete peut etre mal ton français approximatif, aussi le
un item est ce que tu appelle une ligne
si tu veux
TABLE divisé en item (ligne) divise en valeur (colonne)
si tu veux
divise en sous valeur
ou en un lien vers une autre table
ce qui fait ici 15000*64 liens vers le meme nombre de tables
divise en sous sous valeur ......
ou un autre lien
ce qui fait ici 15000*64*360 liens vers le meme nombre de tables puis
ce qui fait ici 15000*64*360*64 liens vers le meme nombre de tables
meilleur moyen serait que tu donnes un fichier test.
T'as qu'à anonymiser le fichier en question.
un fichier test de 200Mo :-)
Pour info mon fichier de test fait 1,7 Go, alors tes 200 Mo...
Je serai vraiment interssé par un test de ma moulinette. A ce stade
de la discussion je reste persuadé que ton fichier passera sans
probleme. Je ne demande qu'a avoir un jeu de test qui me
permettrait soit de reconnaitre publiquement l'infériorité des SGBD
classique (postgresql en l'occurence), soit...
Mais tu as peut etre peur du resultat ? :-D
cree un fichier xml ayant 15000 occurence contenant chacune 64 sous
ocurence de 360 sous sous occurences de 64 sous sous sous occurences
T'as changé :-)
Là tu as 15000 * 64 * 360 * 64 = 22118400000 valeurs au bout
Ton fichier faisant 200 Mo ca laisse
0,0094814814814814814814814814814815 octet par donnée sans compter la
place prise par les balises XML....
Ta proposition est incohérente avec tes affirmations
Ou alors voulais tu dire (cf. ton premier discours) :
Cree un fichier XML ayant 15000 occurences dont *une* contient 64
sous ocurence dont une contient 360 sous sous occurences dont une
contient 64 sous sous sous occurences
je reformules
le fichier epasqy.xml
contient 15000 occurrences
chaque occurrence contient entre 1 et 64 sous occurrence
chaque sous occurrence contient entre 1 et 360 sous sous occurrence
chaque sous sous occurrence contient entre 1 et 64 sous sous sous
occurrence
et une des occurrences a 64 sous occurrences ddonc une qui contient 360
sous sous occurrence donc une contient 64 sous sous sous occurrences
ce qui en structure mono value
oblige a créer une table de 15000 ligne pointant sur 1 a 64 tables
chacune qui elle même pointe sur 1 a 360 tables chacune qui pointe elle
même sur 1 a 64 tables chacune
admettons que chaque ligne pointe en moyenne sur 6 tables de niveau1
admettons que chaque table de niveau 1 pointe en moyenne sur 36 tables
de niveau2
admettons que chaque table de niveau2 pointe sur 6 table de niveau3
cela donne quand même 15000x6x36x6 table soit 19440000 table a créer
la réalité pour appeler les occurrences par leur nom le fichier EPASQY
contient la liste de 15000 terrains issus du regroupement de 1 a 64 lots
qui étaient constitué de 1 a 360 parcelles qui provenaient de la fusion
de 1 a 64 terrains
alors comment réagi ta moulinette pour transformer ce genre de fichier
xml en base monovalué ? forfait ?
helios a écrit :Alain Montfranc a écrit :helios a écritAlain Montfranc a écrit :helios a écritA priori il n'y a pas 1474560 tables dans ton exemple, mais 1
table à 64 lignes liée à une table dont un identifiant correspond
à 360 valeurs (relation 1...360) liée à une table par une
relation 1...64. Je pense que tu confonds valeur et table.
non il y a 15000 item donc un a 64 valeurs donc une a 360 sous
valeur donc une a 64 sous sous valeur
les valeurs sont differente d'un item a l'autre
ce qui donne 1 table de 15000 lignes ......
Ce qui est minuscule :-D
Mais tu parlaius de 17000 tables. Elles sont ou ?
15000 lignes de 64 valeurs qui ont chacune 360 lien et
360 fichiers ayant chacun 64 liens vers 64 fichiers ce qui donne un
total de 15000*64*360*64 tables pour avoir une achitecture type
monovaluéMais j'interprete peut etre mal ton français approximatif, aussi le
un item est ce que tu appelle une ligne
si tu veuxTABLE divisé en item (ligne) divise en valeur (colonne)
si tu veuxdivise en sous valeur
ou en un lien vers une autre table
ce qui fait ici 15000*64 liens vers le meme nombre de tablesdivise en sous sous valeur ......
ou un autre lien
ce qui fait ici 15000*64*360 liens vers le meme nombre de tables puis
ce qui fait ici 15000*64*360*64 liens vers le meme nombre de tablesmeilleur moyen serait que tu donnes un fichier test.
T'as qu'à anonymiser le fichier en question.
un fichier test de 200Mo :-)
Pour info mon fichier de test fait 1,7 Go, alors tes 200 Mo...
Je serai vraiment interssé par un test de ma moulinette. A ce stade
de la discussion je reste persuadé que ton fichier passera sans
probleme. Je ne demande qu'a avoir un jeu de test qui me
permettrait soit de reconnaitre publiquement l'infériorité des SGBD
classique (postgresql en l'occurence), soit...
Mais tu as peut etre peur du resultat ? :-D
cree un fichier xml ayant 15000 occurence contenant chacune 64 sous
ocurence de 360 sous sous occurences de 64 sous sous sous occurences
T'as changé :-)
Là tu as 15000 * 64 * 360 * 64 = 22118400000 valeurs au bout
Ton fichier faisant 200 Mo ca laisse
0,0094814814814814814814814814814815 octet par donnée sans compter la
place prise par les balises XML....
Ta proposition est incohérente avec tes affirmations
Ou alors voulais tu dire (cf. ton premier discours) :
Cree un fichier XML ayant 15000 occurences dont *une* contient 64
sous ocurence dont une contient 360 sous sous occurences dont une
contient 64 sous sous sous occurences
je reformules
le fichier epasqy.xml
contient 15000 occurrences
chaque occurrence contient entre 1 et 64 sous occurrence
chaque sous occurrence contient entre 1 et 360 sous sous occurrence
chaque sous sous occurrence contient entre 1 et 64 sous sous sous
occurrence
et une des occurrences a 64 sous occurrences ddonc une qui contient 360
sous sous occurrence donc une contient 64 sous sous sous occurrences
ce qui en structure mono value
oblige a créer une table de 15000 ligne pointant sur 1 a 64 tables
chacune qui elle même pointe sur 1 a 360 tables chacune qui pointe elle
même sur 1 a 64 tables chacune
admettons que chaque ligne pointe en moyenne sur 6 tables de niveau1
admettons que chaque table de niveau 1 pointe en moyenne sur 36 tables
de niveau2
admettons que chaque table de niveau2 pointe sur 6 table de niveau3
cela donne quand même 15000x6x36x6 table soit 19440000 table a créer
la réalité pour appeler les occurrences par leur nom le fichier EPASQY
contient la liste de 15000 terrains issus du regroupement de 1 a 64 lots
qui étaient constitué de 1 a 360 parcelles qui provenaient de la fusion
de 1 a 64 terrains
alors comment réagi ta moulinette pour transformer ce genre de fichier
xml en base monovalué ? forfait ?
helios a écritTu pretends avoir un fichier de test de 200 Mo qui ferait echouer ma
moulinette. Merci de le communiquer ou de communiquer un moyen de le
générer (dans un langage comme C ou shell svp).
je te l'ai donner dans en basic qui est le language le plus distribue
au monde (1 exemplaire dans chaque systeme microsoft depuis 1981 mSDOS
a WINDOWS VISTA)
a toi de convertir dans le language de ton choix mais pour moi le C
etant moins performant que le databasic des SGBDRMV je n'ai pas perdu
de temp a l'apprendre (il a exister un compilateur C sous SGBDRMV donc
le seul utilisateur a ete la boite qui l'avait produit)Une fois le fichier en ma possession je publierai les resultats de
manière objective.
je t ai detaille la structure precise dans le post suivant alors fait
toi un fichier test repondant si tu veux pas utilise la routine basic
pour le creer
Le fichier de test que tu proposes ne fait pas les 200 Mo annoncés mais
bcp plus.
Il contient en effet 15000 * 64 * 360 * 64 éléments terminaux, soient
22118400000 "feuilles"
Donc, premiere remarque : tu contredis ton affirmation qu'un simple
fichier de 200 Mo suffirait à planter mon truc puisque tu es obligé de
sortir un machin énorme pour tenter de prouver tes dire.
Ensuite, le probleme que tu poses est un simple probleme de stockage car
la structure de ton exemple est simplissime en SGBD classique :
Une premiere table de 15000 lignes, chaque ligne est identifiée par un
id unique
Une seconde table liée à la premiere par cet Id, contenant 64 ligne pour
chaque Id, chaque ligne ayant elle meme un identifiant unique (de 1 à
15000 * 64 donc)
Puis une troisieme table liée à la seconde, etc...
Bref ton machin se resume à 4 tables lies entre elles, par des milliers :-D
lol
vachement utile le multivalué...
helios a écrit
Tu pretends avoir un fichier de test de 200 Mo qui ferait echouer ma
moulinette. Merci de le communiquer ou de communiquer un moyen de le
générer (dans un langage comme C ou shell svp).
je te l'ai donner dans en basic qui est le language le plus distribue
au monde (1 exemplaire dans chaque systeme microsoft depuis 1981 mSDOS
a WINDOWS VISTA)
a toi de convertir dans le language de ton choix mais pour moi le C
etant moins performant que le databasic des SGBDRMV je n'ai pas perdu
de temp a l'apprendre (il a exister un compilateur C sous SGBDRMV donc
le seul utilisateur a ete la boite qui l'avait produit)
Une fois le fichier en ma possession je publierai les resultats de
manière objective.
je t ai detaille la structure precise dans le post suivant alors fait
toi un fichier test repondant si tu veux pas utilise la routine basic
pour le creer
Le fichier de test que tu proposes ne fait pas les 200 Mo annoncés mais
bcp plus.
Il contient en effet 15000 * 64 * 360 * 64 éléments terminaux, soient
22118400000 "feuilles"
Donc, premiere remarque : tu contredis ton affirmation qu'un simple
fichier de 200 Mo suffirait à planter mon truc puisque tu es obligé de
sortir un machin énorme pour tenter de prouver tes dire.
Ensuite, le probleme que tu poses est un simple probleme de stockage car
la structure de ton exemple est simplissime en SGBD classique :
Une premiere table de 15000 lignes, chaque ligne est identifiée par un
id unique
Une seconde table liée à la premiere par cet Id, contenant 64 ligne pour
chaque Id, chaque ligne ayant elle meme un identifiant unique (de 1 à
15000 * 64 donc)
Puis une troisieme table liée à la seconde, etc...
Bref ton machin se resume à 4 tables lies entre elles, par des milliers :-D
lol
vachement utile le multivalué...
helios a écritTu pretends avoir un fichier de test de 200 Mo qui ferait echouer ma
moulinette. Merci de le communiquer ou de communiquer un moyen de le
générer (dans un langage comme C ou shell svp).
je te l'ai donner dans en basic qui est le language le plus distribue
au monde (1 exemplaire dans chaque systeme microsoft depuis 1981 mSDOS
a WINDOWS VISTA)
a toi de convertir dans le language de ton choix mais pour moi le C
etant moins performant que le databasic des SGBDRMV je n'ai pas perdu
de temp a l'apprendre (il a exister un compilateur C sous SGBDRMV donc
le seul utilisateur a ete la boite qui l'avait produit)Une fois le fichier en ma possession je publierai les resultats de
manière objective.
je t ai detaille la structure precise dans le post suivant alors fait
toi un fichier test repondant si tu veux pas utilise la routine basic
pour le creer
Le fichier de test que tu proposes ne fait pas les 200 Mo annoncés mais
bcp plus.
Il contient en effet 15000 * 64 * 360 * 64 éléments terminaux, soient
22118400000 "feuilles"
Donc, premiere remarque : tu contredis ton affirmation qu'un simple
fichier de 200 Mo suffirait à planter mon truc puisque tu es obligé de
sortir un machin énorme pour tenter de prouver tes dire.
Ensuite, le probleme que tu poses est un simple probleme de stockage car
la structure de ton exemple est simplissime en SGBD classique :
Une premiere table de 15000 lignes, chaque ligne est identifiée par un
id unique
Une seconde table liée à la premiere par cet Id, contenant 64 ligne pour
chaque Id, chaque ligne ayant elle meme un identifiant unique (de 1 à
15000 * 64 donc)
Puis une troisieme table liée à la seconde, etc...
Bref ton machin se resume à 4 tables lies entre elles, par des milliers :-D
lol
vachement utile le multivalué...
360 groupes de places de parking donc un avait ete [...]
360 groupes de places de parking donc un avait ete [...]
360 groupes de places de parking donc un avait ete [...]
helios a écrit
je reformules
halon y
le fichier epasqy.xml
contient 15000 occurrences
oui
chaque occurrence contient entre 1 et 64 sous occurrence
chaque sous occurrence contient entre 1 et 360 sous sous occurrence
chaque sous sous occurrence contient entre 1 et 64 sous sous sous
occurrence
et une des occurrences a 64 sous occurrences ddonc une qui contient
360 sous sous occurrence donc une contient 64 sous sous sous occurrences
ce qui en structure mono value
oblige a créer une table de 15000 ligne pointant sur 1 a 64 tables
chacune
non, pas besoin de 64 tables, une suffit
snip le reste des élucubrations.
helios a écrit
je reformules
halon y
le fichier epasqy.xml
contient 15000 occurrences
oui
chaque occurrence contient entre 1 et 64 sous occurrence
chaque sous occurrence contient entre 1 et 360 sous sous occurrence
chaque sous sous occurrence contient entre 1 et 64 sous sous sous
occurrence
et une des occurrences a 64 sous occurrences ddonc une qui contient
360 sous sous occurrence donc une contient 64 sous sous sous occurrences
ce qui en structure mono value
oblige a créer une table de 15000 ligne pointant sur 1 a 64 tables
chacune
non, pas besoin de 64 tables, une suffit
snip le reste des élucubrations.
helios a écrit
je reformules
halon y
le fichier epasqy.xml
contient 15000 occurrences
oui
chaque occurrence contient entre 1 et 64 sous occurrence
chaque sous occurrence contient entre 1 et 360 sous sous occurrence
chaque sous sous occurrence contient entre 1 et 64 sous sous sous
occurrence
et une des occurrences a 64 sous occurrences ddonc une qui contient
360 sous sous occurrence donc une contient 64 sous sous sous occurrences
ce qui en structure mono value
oblige a créer une table de 15000 ligne pointant sur 1 a 64 tables
chacune
non, pas besoin de 64 tables, une suffit
snip le reste des élucubrations.
je presente autrement pour te faire comprendre avec des noms pour les niveaux
niveau 1 tu_ as une liste de 15000 villes
niveau2 c'est les nom des quartiers des villes (1 a 64 quartiers par villes)
les quartiers des villes ne sont pas commun a plusieurs villes
je presente autrement pour te faire comprendre avec des noms pour les niveaux
niveau 1 tu_ as une liste de 15000 villes
niveau2 c'est les nom des quartiers des villes (1 a 64 quartiers par villes)
les quartiers des villes ne sont pas commun a plusieurs villes
je presente autrement pour te faire comprendre avec des noms pour les niveaux
niveau 1 tu_ as une liste de 15000 villes
niveau2 c'est les nom des quartiers des villes (1 a 64 quartiers par villes)
les quartiers des villes ne sont pas commun a plusieurs villes
ALain Montfranc a écrit :helios a écritDonc en préliminaire tu admets avoir eu tord ?il n'y a pas besoin non plus d'avoir un camion pour transporter plusieurs
dizaine de tonne de sable une brouette peut le faire :-)
Pourtant tu disais :XML est multivalué il te *faut* donc utilise un SGBDR multivalué
*sinon* tu as une perte d'information
C'était donc faux ?
comme il y a pas besoin d'un camion parce que une brouette peut le remplacer
Quel est donc l'interet des SGBD multivalués ? ;-)quel est l'intérêt d'un camion ? ;-)
Il y a une difference : il existe des objets qu'une brouette ne peut pas
transporter (un arbre, une cuve à mazout de 3000 litres, etc...). Par
contra j'attends toujours un exemple de fichier XML que ma
brouette/moulinette ne sait pas gérer...
une brouette peut transporter un arbre aprés l'avoir découper avec une scie
ta moulinette ne geres pas elle decoupe ce qui est different
le fichier de 353ko n'est pas convertie en un fichier mais decouper en plus
de 100 fichier
ta moulinette semble faire la conversion mais que donne en exploitation
le resultat ?
Ton objection d'origine était une hypothétique perte d'information. Tu
admets que c'était faux ?
a vérifier la non perte d'info le découpage a été fait mais cela ne prouve
rien d'autre que le découpage possible
ALain Montfranc a écrit :
helios a écrit
Donc en préliminaire tu admets avoir eu tord ?
il n'y a pas besoin non plus d'avoir un camion pour transporter plusieurs
dizaine de tonne de sable une brouette peut le faire :-)
Pourtant tu disais :
XML est multivalué il te *faut* donc utilise un SGBDR multivalué
*sinon* tu as une perte d'information
C'était donc faux ?
comme il y a pas besoin d'un camion parce que une brouette peut le remplacer
Quel est donc l'interet des SGBD multivalués ? ;-)
quel est l'intérêt d'un camion ? ;-)
Il y a une difference : il existe des objets qu'une brouette ne peut pas
transporter (un arbre, une cuve à mazout de 3000 litres, etc...). Par
contra j'attends toujours un exemple de fichier XML que ma
brouette/moulinette ne sait pas gérer...
une brouette peut transporter un arbre aprés l'avoir découper avec une scie
ta moulinette ne geres pas elle decoupe ce qui est different
le fichier de 353ko n'est pas convertie en un fichier mais decouper en plus
de 100 fichier
ta moulinette semble faire la conversion mais que donne en exploitation
le resultat ?
Ton objection d'origine était une hypothétique perte d'information. Tu
admets que c'était faux ?
a vérifier la non perte d'info le découpage a été fait mais cela ne prouve
rien d'autre que le découpage possible
ALain Montfranc a écrit :helios a écritDonc en préliminaire tu admets avoir eu tord ?il n'y a pas besoin non plus d'avoir un camion pour transporter plusieurs
dizaine de tonne de sable une brouette peut le faire :-)
Pourtant tu disais :XML est multivalué il te *faut* donc utilise un SGBDR multivalué
*sinon* tu as une perte d'information
C'était donc faux ?
comme il y a pas besoin d'un camion parce que une brouette peut le remplacer
Quel est donc l'interet des SGBD multivalués ? ;-)quel est l'intérêt d'un camion ? ;-)
Il y a une difference : il existe des objets qu'une brouette ne peut pas
transporter (un arbre, une cuve à mazout de 3000 litres, etc...). Par
contra j'attends toujours un exemple de fichier XML que ma
brouette/moulinette ne sait pas gérer...
une brouette peut transporter un arbre aprés l'avoir découper avec une scie
ta moulinette ne geres pas elle decoupe ce qui est different
le fichier de 353ko n'est pas convertie en un fichier mais decouper en plus
de 100 fichier
ta moulinette semble faire la conversion mais que donne en exploitation
le resultat ?
Ton objection d'origine était une hypothétique perte d'information. Tu
admets que c'était faux ?
a vérifier la non perte d'info le découpage a été fait mais cela ne prouve
rien d'autre que le découpage possible
ALain Montfranc a écrit :helios a écritDonc en préliminaire tu admets avoir eu tord ?il n'y a pas besoin non plus d'avoir un camion pour transporter plusieurs
dizaine de tonne de sable une brouette peut le faire :-)
Pourtant tu disais :XML est multivalué il te *faut* donc utilise un SGBDR multivalué
*sinon* tu as une perte d'information
C'était donc faux ?
comme il y a pas besoin d'un camion parce que une brouette peut le
remplacer
Quel est donc l'interet des SGBD multivalués ? ;-)quel est l'intérêt d'un camion ? ;-)
Il y a une difference : il existe des objets qu'une brouette ne peut pas
transporter (un arbre, une cuve à mazout de 3000 litres, etc...). Par
contra j'attends toujours un exemple de fichier XML que ma
brouette/moulinette ne sait pas gérer...
une brouette peut transporter un arbre aprés l'avoir découper avec une scie
ta moulinette ne geres pas elle decoupe ce qui est different
le fichier de 353ko n'est pas convertie en un fichier mais decouper en plus
de 100 fichier
ta moulinette semble faire la conversion mais que donne en exploitation
le resultat ?
Ton objection d'origine était une hypothétique perte d'information. Tu
admets que c'était faux ?
a vérifier la non perte d'info le découpage a été fait mais cela ne prouve
rien d'autre que le découpage possible
ALain Montfranc a écrit :
helios a écrit
Donc en préliminaire tu admets avoir eu tord ?
il n'y a pas besoin non plus d'avoir un camion pour transporter plusieurs
dizaine de tonne de sable une brouette peut le faire :-)
Pourtant tu disais :
XML est multivalué il te *faut* donc utilise un SGBDR multivalué
*sinon* tu as une perte d'information
C'était donc faux ?
comme il y a pas besoin d'un camion parce que une brouette peut le
remplacer
Quel est donc l'interet des SGBD multivalués ? ;-)
quel est l'intérêt d'un camion ? ;-)
Il y a une difference : il existe des objets qu'une brouette ne peut pas
transporter (un arbre, une cuve à mazout de 3000 litres, etc...). Par
contra j'attends toujours un exemple de fichier XML que ma
brouette/moulinette ne sait pas gérer...
une brouette peut transporter un arbre aprés l'avoir découper avec une scie
ta moulinette ne geres pas elle decoupe ce qui est different
le fichier de 353ko n'est pas convertie en un fichier mais decouper en plus
de 100 fichier
ta moulinette semble faire la conversion mais que donne en exploitation
le resultat ?
Ton objection d'origine était une hypothétique perte d'information. Tu
admets que c'était faux ?
a vérifier la non perte d'info le découpage a été fait mais cela ne prouve
rien d'autre que le découpage possible
ALain Montfranc a écrit :helios a écritDonc en préliminaire tu admets avoir eu tord ?il n'y a pas besoin non plus d'avoir un camion pour transporter plusieurs
dizaine de tonne de sable une brouette peut le faire :-)
Pourtant tu disais :XML est multivalué il te *faut* donc utilise un SGBDR multivalué
*sinon* tu as une perte d'information
C'était donc faux ?
comme il y a pas besoin d'un camion parce que une brouette peut le
remplacer
Quel est donc l'interet des SGBD multivalués ? ;-)quel est l'intérêt d'un camion ? ;-)
Il y a une difference : il existe des objets qu'une brouette ne peut pas
transporter (un arbre, une cuve à mazout de 3000 litres, etc...). Par
contra j'attends toujours un exemple de fichier XML que ma
brouette/moulinette ne sait pas gérer...
une brouette peut transporter un arbre aprés l'avoir découper avec une scie
ta moulinette ne geres pas elle decoupe ce qui est different
le fichier de 353ko n'est pas convertie en un fichier mais decouper en plus
de 100 fichier
ta moulinette semble faire la conversion mais que donne en exploitation
le resultat ?
Ton objection d'origine était une hypothétique perte d'information. Tu
admets que c'était faux ?
a vérifier la non perte d'info le découpage a été fait mais cela ne prouve
rien d'autre que le découpage possible