optimiser une requete qui doit de toute façon lire toute la base

Le 29-05-2010, ? propos de
Re: optimiser une requete qui doit de toute façon lire toute la base,
helios ?crivait dans fr.comp.applications.sgbd :

JKB a écrit :

Le 29-05-2010, ? propos de
Re: optimiser une requete qui doit de toute façon lire toute la base,
helios ?crivait dans fr.comp.applications.sgbd :

SQLpro a écrit :

WebShaker a écrit :

salut.

on me demande de réaliser une requête qui consiste a compter le
nombre de produit vendu par référence.

il s'agit donc de
SELECT ref, count(*) FROM commandline GROUP BY ref;

mais j'ai 17.000.000 de lignes de de commandes dans ma base...
Alors la question est simple.
que peut on faire pour optimiser ce genre de requête...

la solution est de mettre en place une vue matérialisée (Oracle, DB2)
ou indexées (SQL Server).

Exemple sous MS SQL Server :

CREATE VIEW dbo.V_commandline
WITH SCHEMABINDING
AS
SELECT ref, count_big(*) AS NOMBRE
FROM dbo.commandline
GROUP BY ref;
GO

CREATE UNIQUE CLUSTERED INDEX X_V_commandline
ON dbo.V_commandline (ref);

Dès lors votre requête :

SELECT ref, count(*) FROM commandline GROUP BY ref
Mettra 0 secondes et consommera environ 2 pages !

A +

et le codagedes dates depuis JC à nos jours peut se faire sur 2octets ????

Tu es vraiment un abruti de première classe avec palme et
fourragère [1]. Lâche-le avec ça. Si tout le monde ici te mettait à
chacune de tes interventions nullissimes le nez dans tes erreurs, on
n'en finirait pas !

Quant à la discussion actuelle sur Wikipedia, elle montre à tous
ceux qui ne te connaissait pas encore la profondeur de tes
connaissances. Tout ce que tu prétends faire avec PICK, on peut le
faire au moins aussi bien avec SQL (et ce n'est pas une histoire de
lisibilité). Ce que je n'arrive pas à comprendre, c'est qu'il y ait
encore quelqu'un à jouer avec toi sur Wikipedia. Un autre mystère
est pour moi ta capacité à prétendre faire des choses avec un
système de base de données sans en connaître le fonctionnement
interne minimal ! Et je passe sur le fait que tu racontes un peu
partout des exploits professionnels à des endroits où j'aurais dû te
voir...

JKB

[1] et je ne parlerai pas de ton doctorat, parce qu'il y aurait beaucoup
de choses à dire. Que les nouveaux venus recherchent dans les archives
de ce groupe.

PS: répond ce que tu veux, je n'entrerai pas dans ton jeu.

je te signales que les endroits ou tu pretend que tu aurais du me voir
toi tu y etait pas car tes justificatifs de presence etait incoherent
style je rentre dans un etablissement sans que le patron le sache ......

C'est surtout toi qui prétends que j'aurais dû avoir l'aval du chef
du lieu, ce qui est tout à fait autre chose. Ça prouve juste à quel
point tu connais le fonctionnement de France Telecom à cette époque.

je vais te donner tient une preuve une des peri42c se nomme ADSL.COV et
a ete ecrite par Cliquet Jacky UIC le 01/06/2003 et c'est le " Programme
permettant de connaitre le nombre de clients sur un Centre
Afin de savoir la possibilite d'un furture couverture ADSL"

alors si tu a vraiment ete a france telecom tu doit pouvoir me donner le
nom d'une autre peri42C avec son auteur et son role

Tu ne peux pas savoir comme je me contre-fiche de tes arguments et
de tes soi-disant preuves. Tu essayes de te raccrocher à toutes les
branches existantes parce que c'est le seul moyen pour toi de ne pas
passer pour un charlot. Comme tous les gens de ton espèces, tu la
ramènes toujours en chageant le sujet parce que la discussion
dérivait vers tes manquements.

J'ai des fiches de salaire du CNET puis de FT R&D, je peux même te
donner le numéro de mon ancien bureau. Je bossais justement sur des
problèmes informatiques en général (pour unifier le système
d'information) et de base de données en particulier. Je ne prétends
pas connaître dans le détail tous les systèmes utilisés, mais
lorsque j'ai quitté FT R&D en octobre 1998, personne dans mon département
ne bossait sur un système multivalué. Lorsqu'on a travaillé sur les
histoires de bases de clients pour les accès internet, personne n'a
ne serait-ce qu'un moment envisagé autre chose que du relationnel
(pour des raisons que je ne vais pas perdre du temps à t'expliquer,
obtus comme tu es !). Et dans les centres que j'ai pu
voir (rassure-toi avec l'aval de tout le monde vu que j'étais du
centre de recherche, et les noms des responsables des centres étaient le
_cadet_ de mes soucis vu que je n'avais pas affaire à eux), je n'ai jamais
vu une seule application PICK ou prétendue telle.
Et je te prie de croire que j'en ai fait, de l'audit de base de
données pour unifier tout ce beau petit monde !
Du RDB, du SQL et des trucs plus exotiques que tu ne peux même pas
arriver à imaginer, dont certains sous des OS improbables, j'en ai
pourtant vu. Et des trucs exotiques, il y en avait en pagaille, fruit
de l'époque où à chaque besoin, on se coltinait le petit programme qui
fait tout ! En 1998, je suis tombé sur un obscur système de base de
données codé à la main sous UniFLEX que personne n'avait touché depuis
quinze ans et qui remplissait parfaitement son boulot, mais plus
personne ne savait comment ! Entre le bricolage radiocom 200
injecté à coups de patches dans le système radiocom 2000, lui-même
balancé à la va-comme-je-te-pousse dans le système Itinéris sectorisé
avant d'unifier la base sur le plan national, c'était la pagaille. En
rajoutant là-dessus les kiosques et les abonnements internet, c'était
le vrai foutoir pour la facturation et le suivi de clientèle. Mais dans
tout ce foutoir, je n'ai jamais vu de PICK. Du COBOL, des fichiers
indexés sous VMS, des systèmes relationnels, en pagaille, mais du PICK,
_jamais_. Cela veut juste dire une chose : s'il y en avait, c'était
anecdotique, parce que si cela ne l'était pas, on aurait un jour ou
l'autre eu à s'en coltiner.

Maintenant, je connais aussi très bien France Telecom pour savoir
qu'à l'époque, on gardait des vieux de la vieille en leur faisant
faire des trucs pas trop utiles dans leur coin, mais pour justifier
leur salaire. Et ça pourra peut-être servir un jour, on ne sait
jamais. C'est même pour cela que j'en suis parti. C'est juste
histoire de te faire comprendre que ce n'est pas parce que tu vas
trouver une application tordue dans un coin qu'elle est utilisable
ou utilisée.

Au fait, juste pour enfoncer le clou : on avait _deux_ contraintes
pour la refonte du SI : que ça tourne sous HP-UX (au pire sous
OpenVMS). Tout le centre de calcul pour la migration tournait sous
HP-UX 9.03 (une catastrophe) ou 10.20, des serveurs flambant neufs
K9000 quadripro HPPA.

Je te plains sincèrement. Ton seul but dans l'existence est
d'essayer de prouver que le multivalué en général et PICK en
particulier sont supérieurs au relationnel. Ce qui prouve juste que
tu n'as rien compris. Le multivalué, c'est juste une jointure dans
ton dos qui ne dit pas son nom. Que tu sois persuadé du contraire
prouve juste que tu ne sais pas de quoi tu parles et met le doigt
sur tes limites techniques. Je ne dis pas que tu es mauvais dans ce
que tu fais, simplement qu'à côté de ce que tu fais, donc à côté du
multivalué, tu es parfaitement incompétent. La discussion sur ta
page Wikipedia est d'ailleurs éloquente. Le coup des distances des
villes, c'est fait en _une_ requête spatiale PostgreSQL/PostGIS et
ton interlocuteur t'a parfaitement indiqué qu'il n'était pas
spécialiste. Il t'a juste montré que c'était faisable. Bizarement,
tu es passé à autre chose... Oui, _une_ requête pas plus longue que
la tienne. Ton contradicteur a juste écrit le calcul de distance à
la main plutôt que d'utiliser la fonction qui va bien. Au passage,
j'espère simplement que PICK n'utilise pas comme tu semblait
l'indiquer le théorème de Pythagore sur un triangle quasiment
_spérique_. Je ne sais pas si tu vois bien de quoi je veux parler...

Que tu te fasses jeter de Wikipedia régulièrement, ce n'est pas
parce que tu écris le français comme un goret (encore que n'étant
pas franchement de langue maternelle française, j'estime que des
français se doivent d'écrire un minimum correctement leur langue) et
que tes raisonnements sont incompréhensibles, c'est juste parce que tu
persistes à raconter n'importe quoi au mépris de tes interlocuteurs
et surtout parce que tes arguties sont sans fondement.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

helios a pensé très fort :

et le codagedes dates depuis JC à nos jours peut se faire sur 2octets ????

Et "almost" veut dire "distribué" ?

JKB a écrit :

Le 29-05-2010, ? propos de
Re: optimiser une requete qui doit de toute façon lire toute la base,
helios ?crivait dans fr.comp.applications.sgbd :

JKB a écrit :

Le 29-05-2010, ? propos de
Re: optimiser une requete qui doit de toute façon lire toute la base,
helios ?crivait dans fr.comp.applications.sgbd :

SQLpro a écrit :

WebShaker a écrit :

salut.

on me demande de réaliser une requête qui consiste a compter le
nombre de produit vendu par référence.

il s'agit donc de
SELECT ref, count(*) FROM commandline GROUP BY ref;

mais j'ai 17.000.000 de lignes de de commandes dans ma base...
Alors la question est simple.
que peut on faire pour optimiser ce genre de requête...

la solution est de mettre en place une vue matérialisée (Oracle, DB2)
ou indexées (SQL Server).

Exemple sous MS SQL Server :

CREATE VIEW dbo.V_commandline
WITH SCHEMABINDING
AS
SELECT ref, count_big(*) AS NOMBRE
FROM dbo.commandline
GROUP BY ref;
GO

CREATE UNIQUE CLUSTERED INDEX X_V_commandline
ON dbo.V_commandline (ref);

Dès lors votre requête :

SELECT ref, count(*) FROM commandline GROUP BY ref
Mettra 0 secondes et consommera environ 2 pages !

A +

et le codagedes dates depuis JC à nos jours peut se faire sur 2octets ????

Tu es vraiment un abruti de première classe avec palme et
fourragère [1]. Lâche-le avec ça. Si tout le monde ici te mettait à
chacune de tes interventions nullissimes le nez dans tes erreurs, on
n'en finirait pas !

Quant à la discussion actuelle sur Wikipedia, elle montre à tous
ceux qui ne te connaissait pas encore la profondeur de tes
connaissances. Tout ce que tu prétends faire avec PICK, on peut le
faire au moins aussi bien avec SQL (et ce n'est pas une histoire de
lisibilité). Ce que je n'arrive pas à comprendre, c'est qu'il y ait
encore quelqu'un à jouer avec toi sur Wikipedia. Un autre mystère
est pour moi ta capacité à prétendre faire des choses avec un
système de base de données sans en connaître le fonctionnement
interne minimal ! Et je passe sur le fait que tu racontes un peu
partout des exploits professionnels à des endroits où j'aurais dû te
voir...

JKB

[1] et je ne parlerai pas de ton doctorat, parce qu'il y aurait beaucoup
de choses à dire. Que les nouveaux venus recherchent dans les archives
de ce groupe.

PS: répond ce que tu veux, je n'entrerai pas dans ton jeu.

je te signales que les endroits ou tu pretend que tu aurais du me voir
toi tu y etait pas car tes justificatifs de presence etait incoherent
style je rentre dans un etablissement sans que le patron le sache ......

C'est surtout toi qui prétends que j'aurais dû avoir l'aval du chef
du lieu, ce qui est tout à fait autre chose. Ça prouve juste à quel
point tu connais le fonctionnement de France Telecom à cette époque.

je vais te donner tient une preuve une des peri42c se nomme ADSL.COV et
a ete ecrite par Cliquet Jacky UIC le 01/06/2003 et c'est le " Programme
permettant de connaitre le nombre de clients sur un Centre
Afin de savoir la possibilite d'un furture couverture ADSL"

alors si tu a vraiment ete a france telecom tu doit pouvoir me donner le
nom d'une autre peri42C avec son auteur et son role

Tu ne peux pas savoir comme je me contre-fiche de tes arguments et
de tes soi-disant preuves. Tu essayes de te raccrocher à toutes les
branches existantes parce que c'est le seul moyen pour toi de ne pas
passer pour un charlot. Comme tous les gens de ton espèces, tu la
ramènes toujours en chageant le sujet parce que la discussion
dérivait vers tes manquements.

J'ai des fiches de salaire du CNET puis de FT R&D, je peux même te
donner le numéro de mon ancien bureau. Je bossais justement sur des
problèmes informatiques en général (pour unifier le système
d'information) et de base de données en particulier. Je ne prétends
pas connaître dans le détail tous les systèmes utilisés, mais
lorsque j'ai quitté FT R&D en octobre 1998, personne dans mon département
ne bossait sur un système multivalué. Lorsqu'on a travaillé sur les
histoires de bases de clients pour les accès internet, personne n'a
ne serait-ce qu'un moment envisagé autre chose que du relationnel
(pour des raisons que je ne vais pas perdre du temps à t'expliquer,
obtus comme tu es !). Et dans les centres que j'ai pu
voir (rassure-toi avec l'aval de tout le monde vu que j'étais du
centre de recherche, et les noms des responsables des centres étaient le
_cadet_ de mes soucis vu que je n'avais pas affaire à eux), je n'ai jamais
vu une seule application PICK ou prétendue telle.
Et je te prie de croire que j'en ai fait, de l'audit de base de
données pour unifier tout ce beau petit monde !
Du RDB, du SQL et des trucs plus exotiques que tu ne peux même pas
arriver à imaginer, dont certains sous des OS improbables, j'en ai
pourtant vu. Et des trucs exotiques, il y en avait en pagaille, fruit
de l'époque où à chaque besoin, on se coltinait le petit programme qui
fait tout ! En 1998, je suis tombé sur un obscur système de base de
données codé à la main sous UniFLEX que personne n'avait touché depuis
quinze ans et qui remplissait parfaitement son boulot, mais plus
personne ne savait comment ! Entre le bricolage radiocom 200
injecté à coups de patches dans le système radiocom 2000, lui-même
balancé à la va-comme-je-te-pousse dans le système Itinéris sectorisé
avant d'unifier la base sur le plan national, c'était la pagaille. En
rajoutant là-dessus les kiosques et les abonnements internet, c'était
le vrai foutoir pour la facturation et le suivi de clientèle. Mais dans
tout ce foutoir, je n'ai jamais vu de PICK. Du COBOL, des fichiers
indexés sous VMS, des systèmes relationnels, en pagaille, mais du PICK,
_jamais_. Cela veut juste dire une chose : s'il y en avait, c'était
anecdotique, parce que si cela ne l'était pas, on aurait un jour ou
l'autre eu à s'en coltiner.

Maintenant, je connais aussi très bien France Telecom pour savoir
qu'à l'époque, on gardait des vieux de la vieille en leur faisant
faire des trucs pas trop utiles dans leur coin, mais pour justifier
leur salaire. Et ça pourra peut-être servir un jour, on ne sait
jamais. C'est même pour cela que j'en suis parti. C'est juste
histoire de te faire comprendre que ce n'est pas parce que tu vas
trouver une application tordue dans un coin qu'elle est utilisable
ou utilisée.

Au fait, juste pour enfoncer le clou : on avait _deux_ contraintes
pour la refonte du SI : que ça tourne sous HP-UX (au pire sous
OpenVMS). Tout le centre de calcul pour la migration tournait sous
HP-UX 9.03 (une catastrophe) ou 10.20, des serveurs flambant neufs
K9000 quadripro HPPA.

la 42C est l'application majeur de FT depuis 1981 et l'etait encore
lorsque j'ai intervenue dessus en 2005
en 1981 cela tournait sur des réalité 2000 de intertechnique avec
IN-PICK en 2005 sur des clusters IBM avec PICK-UNIVERSE
apres qu'a FT il y a des appli mineur sur HP-UX c'est possible

http://www.google.fr/#hl=fr&qBc+france+telecom&aq=0&aqi=g1&aql=&oqBc+&gs_rfai=&fpG82491856b790e6

Alain Montfranc a écrit :

helios a pensé très fort :

et le codagedes dates depuis JC à nos jours peut se faire sur 2octets
????

Et "almost" veut dire "distribué" ?

almost signifie presque

a ce jour le sir Brouard n'a toujour pas admis que l'on ne pouvait pas
coder toute les date depuis JC sur 2 octets et essays toujour s de me
poursuivre en diffamation car il croit que c'est moi qui est denoncer
en premier sa "connerie"

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

Alain Montfranc a écrit :

helios a pensé très fort :

et le codagedes dates depuis JC à nos jours peut se faire sur 2octets ????

Et "almost" veut dire "distribué" ?

almost signifie presque

Tiens, vous arrivez à progresser ? Pas mal...

Alain Montfranc a écrit :

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

Alain Montfranc a écrit :

helios a pensé très fort :

et le codagedes dates depuis JC à nos jours peut se faire sur
2octets ????

Et "almost" veut dire "distribué" ?

almost signifie presque

Tiens, vous arrivez à progresser ? Pas mal...

je suis pas comme Fred ou JKB
fred n'as toujour pas admis avoir dis une grosse connerie en disant
codage date sur 2 octet
et
JKB arrive a pretendre qu'aucune appli est sous pick a FT alors qu'il y
a la 42C une application majeur de FT depuis 1981 et l'etait encore
lorsque j'ai intervenue dessus en 2005
en 1981 cela tournait sur des réalité 2000 de intertechnique avec
IN-PICK en 2005 sur des clusters IBM avec PICK-UNIVERSE
apres qu'a FT il y a des appli mineur sur HP-UX c'est possible et que
JKB est travaillé sur des fossile ou appli mineur a FT est possible

http://www.google.fr/#hl=fr&qBc+france+telecom&aq=0&aqi=g1&aql=&oqBc+&gs_rfai=&fpG82491856b790e6

Le 29-05-2010, ? propos de
Re: optimiser une requete qui doit de toute façon lire toute la base,
helios ?crivait dans fr.comp.applications.sgbd :

Alain Montfranc a écrit :

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

Alain Montfranc a écrit :

helios a pensé très fort :

et le codagedes dates depuis JC à nos jours peut se faire sur
2octets ????

Et "almost" veut dire "distribué" ?

almost signifie presque

Tiens, vous arrivez à progresser ? Pas mal...

je suis pas comme Fred ou JKB
fred n'as toujour pas admis avoir dis une grosse connerie en disant
codage date sur 2 octet
et
JKB arrive a pretendre qu'aucune appli est sous pick a FT alors qu'il y
a la 42C une application majeur de FT depuis 1981 et l'etait encore
lorsque j'ai intervenue dessus en 2005
en 1981 cela tournait sur des réalité 2000 de intertechnique avec
IN-PICK en 2005 sur des clusters IBM avec PICK-UNIVERSE
apres qu'a FT il y a des appli mineur sur HP-UX c'est possible et que
JKB est travaillé sur des fossile ou appli mineur a FT est possible

http://www.google.fr/#hl=fr&qBc+france+telecom&aq=0&aqi=g1&aql=&oqBc+&gs_rfai=&fpG82491856b790e6

Arrête, à chacun de tes posts tu t'enfonces. Tu viens juste de
prouver que tu ne sais pas de quoi tu parles. 42C, c'est comme 20H,
c'est une application (et qui plus est indépendante de la base de
données qui peut se trouver derrière, mais ça risque de t'échapper).
D'ailleurs rajoute PICK à ta recherche et, bizarrement, on
tombe sur toi et deux ou trois types du même tonneau, preuve que
c'est utilisé partout chez France Telecom. Du 42C, on en a fait
tourner sous Oracle au moins en test ! Et le CNET serait content
d'apprendre que ses salles serveurs font tourner des petites applications
mineures avant de les déployer ! Rigolo !

Au passage, depuis que je suis de l'autre côté, j'ai à interfacer
des trucs avec les bases de FT. PIDI, ça s'appelle, et je puis
t'affirmer pour participer aux réunions qu'il n'y a pas un gramme de
PICK dedans ! C'est du pur relationnel et manque de bol pour toi, on
a aussi ce qu'il faut pour attaquer les 42C.

Je crois que tu ne comprends surtout pas que PICK UNIVERSE, c'est
exactement comme Solid (un autre produit IBM), des trucs qui n'existent
encore que parce qu'il y a un parc d'applications existantes, applications
qui sont toutes migrées au fur et à mesure vers des systèmes qui
fonctionnent mieux (ou moins mal, c'est selon).

J'attends toujours d'ailleurs que tu m'expliques - mais certainement
en es-tu incapable - comment un système multivalué (je dis
multivalué, pas bi, tri ou n-valué !) peut fonctionner sans
faire une jointure dans ton dos. Le but d'un système multivalué,
c'est de pouvoir mettre un nombre quelconque de données par champ.
Le problème est dans le quelconque. Soit tu prévois un grand nombre
de champs et tu te retrouves avec des tables qui ressemblent à un
emment(h)al, soit tu en prévois moins et tu risques de perdre des
données, et dans ce cas ton système est n-valué; soit tu utilises un
système à _deux_ tables avec une jointure automatique dans ton dos.
Mais tu ne le sais pas et tu as l'impression que c'est du
multivalué.

Par ailleurs, j'ai regardé dans les sources d'OpenMQ. Tu devrais
essayer de les comprendre. En faisant abstraction du fait que c'est
du goret codage, ça te ferait au moins comprendre que le multivalué,
ce n'est pas du tout ce que tu crois. Quant à PICK UNIVERSE, je n'ai
pas les sources, mais ça doit revenir peu ou prou à la même chose,
parce que je ne vois vraiment pas comment il pourrait en être
différemment.

JKB

PS: lorsque tu essayes de m'adresser la parole, fais le en français
correct. Jeu ne raipondrè pa à un sabir inhintèlijible ait bourrhé deux
phôtes d'eaurtograffe. En attendant, fin de la discussion.

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 29/05/2010 10:14, SQLpro a écrit :

SELECT ref, count(*) FROM commandline GROUP BY ref
Mettra 0 secondes et consommera environ 2 pages !

Tu as un lien qui explique ce qu'est une page ans ce contexte ?

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

JKB a écrit :

Le 29-05-2010, ? propos de
Re: optimiser une requete qui doit de toute façon lire toute la base,
helios ?crivait dans fr.comp.applications.sgbd :

Alain Montfranc a écrit :

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

Alain Montfranc a écrit :

helios a pensé très fort :

et le codagedes dates depuis JC à nos jours peut se faire sur
2octets ????

Et "almost" veut dire "distribué" ?

almost signifie presque

Tiens, vous arrivez à progresser ? Pas mal...

je suis pas comme Fred ou JKB
fred n'as toujour pas admis avoir dis une grosse connerie en disant
codage date sur 2 octet
et
JKB arrive a pretendre qu'aucune appli est sous pick a FT alors qu'il y
a la 42C une application majeur de FT depuis 1981 et l'etait encore
lorsque j'ai intervenue dessus en 2005
en 1981 cela tournait sur des réalité 2000 de intertechnique avec
IN-PICK en 2005 sur des clusters IBM avec PICK-UNIVERSE
apres qu'a FT il y a des appli mineur sur HP-UX c'est possible et que
JKB est travaillé sur des fossile ou appli mineur a FT est possible

http://www.google.fr/#hl=fr&qBc+france+telecom&aq=0&aqi=g1&aql=&oqBc+&gs_rfai=&fpG82491856b790e6

Arrête, à chacun de tes posts tu t'enfonces. Tu viens juste de
prouver que tu ne sais pas de quoi tu parles. 42C, c'est comme 20H,
c'est une application (et qui plus est indépendante de la base de
données qui peut se trouver derrière, mais ça risque de t'échapper).
D'ailleurs rajoute PICK à ta recherche et, bizarrement, on
tombe sur toi et deux ou trois types du même tonneau, preuve que
c'est utilisé partout chez France Telecom. Du 42C, on en a fait
tourner sous Oracle au moins en test ! Et le CNET serait content
d'apprendre que ses salles serveurs font tourner des petites applications
mineures avant de les déployer ! Rigolo !

oui 42C a tourner en test sur oracle c'etait en Aout 2003 ; Aout parce
que les machine sont moins solicité
resultat les machine qui en temps normal etait 30fois trop puissante
avec PICK-UNIVERSE se sont ecroulé au mois Aout avec Oracle charge de
calculk trop importante ; d'ailleurs pourquoi Oracle n'a pas ete
conservé suite a ce test :-)

j'ai biens dit que 42c etait une application il y a aussi 20H et 20Z qui
sont ses deux "soeur" et Etechnicien qui est une verrue ecrite en java

Au passage, depuis que je suis de l'autre côté, j'ai à interfacer
des trucs avec les bases de FT. PIDI, ça s'appelle, et je puis
t'affirmer pour participer aux réunions qu'il n'y a pas un gramme de
PICK dedans ! C'est du pur relationnel et manque de bol pour toi, on
a aussi ce qu'il faut pour attaquer les 42C.

qu'une verrue soit sans pick ne prouve rien et que tu te connectes a une
appli PICK avec du SQL n'a rien de miraculeux puisque PICK-UNIVERSE sait
tres bien faire du SQL , l'homme en general parle mais il sait aussi
pousser des grognement cela ne prouves pas que le meilleur language
humain est le grognement

Je crois que tu ne comprends surtout pas que PICK UNIVERSE, c'est
exactement comme Solid (un autre produit IBM), des trucs qui n'existent
encore que parce qu'il y a un parc d'applications existantes, applications
qui sont toutes migrées au fur et à mesure vers des systèmes qui
fonctionnent mieux (ou moins mal, c'est selon).

quand il y a possibilité de migrer sans perte de performances ce qui
n'est pas le cas de la 42C 20H 20Z de FT

J'attends toujours d'ailleurs que tu m'expliques - mais certainement
en es-tu incapable - comment un système multivalué (je dis
multivalué, pas bi, tri ou n-valué !) peut fonctionner sans
faire une jointure dans ton dos. Le but d'un système multivalué,
c'est de pouvoir mettre un nombre quelconque de données par champ.
Le problème est dans le quelconque. Soit tu prévois un grand nombre
de champs et tu te retrouves avec des tables qui ressemblent à un
emment(h)al, soit tu en prévois moins et tu risques de perdre des
données, et dans ce cas ton système est n-valué; soit tu utilises un
système à _deux_ tables avec une jointure automatique dans ton dos.
Mais tu ne le sais pas et tu as l'impression que c'est du
multivalué.

commence par apprendre ce que sont les champs 7 et 8 d'un article de
dictionnaire de fichier avant de parler de multivalué

Par ailleurs, j'ai regardé dans les sources d'OpenMQ. Tu devrais
essayer de les comprendre. En faisant abstraction du fait que c'est
du goret codage, ça te ferait au moins comprendre que le multivalué,
ce n'est pas du tout ce que tu crois. Quant à PICK UNIVERSE, je n'ai
pas les sources, mais ça doit revenir peu ou prou à la même chose,
parce que je ne vois vraiment pas comment il pourrait en être
différemment.

JKB

PS: lorsque tu essayes de m'adresser la parole, fais le en français
correct. Jeu ne raipondrè pa à un sabir inhintèlijible ait bourrhé deux
phôtes d'eaurtograffe. En attendant, fin de la discussion.

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

rien en fait

sai marant lah plu groce baze de donnai komerssialeux aux monde ait...
chez FT et... sou Oracle !