Comment reconnaitre un bon Linuxien d'un vrai neuneu ?
832 réponses
Xandros
Salut,
Depuis les quelques mois que je suis sous Linux et que je fréquente les
Forums dédiés, j'ai pu remarquer une chose.
Il existe 3 types de personnes :
1) Les novices qui viennent du monde Windows et qui posent pleins de
questions sans vraiment chercher les réponses. J'en faisais parti, mais
je me soigne depuis ;)
2) Les neuneux de base, qui n'y connaissent pas grand chose et qui se
défoulent sur le premier novice venu. On les reconnait par leurs
réponses standards : "trop gros - passera pas" - "va chercher sur
Google" - "Prouves le" - "Vas lire MAN ou HOWTO"
En fait, il n'apportent jamais rien au débat, mais font croire qu'ils
s'y connaissent trop pour perdre leur temps avec des novices.
3) Enfin, les "vrais", ceux qui t'apportent LA solution, on les
reconnait par la simplicité de leurs réponses, un lien, une commande,
une solution quoi.
Un grand merci à eux !!!
Tout ça pour dire que le monde Linux serait bien plus simple si la 2eme
cathégorie pouvait simplement admettre qu'ils font parti de la 1er, ou
alors si ils veulent se prétendre de la 3eme, qu'ils apportent de l'aide
ou bien qu'il ferme leurs gue...le.
--
Message envoyé avec ThunderBird
Sous Linux Xandros Deluxe 3.0
c'est vrai FT a une petite base de 60000000 de ligne telephonique qui contient malgres le MV 500 champs sans le MV cela en ferais combien de champ ?la migration vers oracle a ete un bide
500 champs ? C'est rien du tout ça. N'oublie pas : y'a une mise en cache sur les SGBD modernes. Même s'il fallait 100 ou 150 tables de plus, je t'assure que franchement, c'est pas la mort pour un Oracle ou un PostgresSQL.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
c'est vrai FT a une petite base de 60000000 de ligne telephonique qui
contient malgres le MV 500 champs sans le MV cela en ferais combien de champ
?la migration vers oracle a ete un bide
500 champs ? C'est rien du tout ça. N'oublie pas : y'a une mise en cache
sur les SGBD modernes. Même s'il fallait 100 ou 150 tables de plus, je
t'assure que franchement, c'est pas la mort pour un Oracle ou un
PostgresSQL.
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
c'est vrai FT a une petite base de 60000000 de ligne telephonique qui contient malgres le MV 500 champs sans le MV cela en ferais combien de champ ?la migration vers oracle a ete un bide
500 champs ? C'est rien du tout ça. N'oublie pas : y'a une mise en cache sur les SGBD modernes. Même s'il fallait 100 ou 150 tables de plus, je t'assure que franchement, c'est pas la mort pour un Oracle ou un PostgresSQL.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Stephane TOUGARD
helios wrote:
la tu as deux table pour un MV de niveau 2 tu envisage 128 tables pour un MV de niveau 128?
256 si tu veux, ca pose pas vraiment un probleme. Apres, c'est qu'une histoire de faire les bonnes applis pour retrouver les bonnes donnees au bon endroit, ce qui n'est pas vraiment tres complique.
c'est sur cela se saurait d'ailleur comme il y a que des petites boite qui soutient pick tel ibm; att, siemens, nixdorf, dassault, .... et tres peut d'utilisateur 6000000
On attend toujours un lien pour nous demontrer ce chiffre completement fou. Pour moi, le seul mv utilise par 6 000 000 d'utilisateurs, c'est celui utilise par Unix pour bouger un fichier.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
helios wrote:
la tu as deux table pour un MV de niveau 2 tu envisage 128 tables pour un MV
de niveau 128?
256 si tu veux, ca pose pas vraiment un probleme. Apres, c'est qu'une
histoire de faire les bonnes applis pour retrouver les bonnes donnees au
bon endroit, ce qui n'est pas vraiment tres complique.
c'est sur cela se saurait d'ailleur comme il y a que des petites boite qui
soutient pick tel ibm; att, siemens, nixdorf, dassault, .... et tres peut
d'utilisateur 6000000
On attend toujours un lien pour nous demontrer ce chiffre completement
fou. Pour moi, le seul mv utilise par 6 000 000 d'utilisateurs, c'est
celui utilise par Unix pour bouger un fichier.
--
http://www.unices.org Les meilleurs modules de Perl
http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul
http://artlibre.org/ Free Art License
la tu as deux table pour un MV de niveau 2 tu envisage 128 tables pour un MV de niveau 128?
256 si tu veux, ca pose pas vraiment un probleme. Apres, c'est qu'une histoire de faire les bonnes applis pour retrouver les bonnes donnees au bon endroit, ce qui n'est pas vraiment tres complique.
c'est sur cela se saurait d'ailleur comme il y a que des petites boite qui soutient pick tel ibm; att, siemens, nixdorf, dassault, .... et tres peut d'utilisateur 6000000
On attend toujours un lien pour nous demontrer ce chiffre completement fou. Pour moi, le seul mv utilise par 6 000 000 d'utilisateurs, c'est celui utilise par Unix pour bouger un fichier.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
Jerome Lambert
"Stephane TOUGARD" a écrit dans le message de (...)
Apres tu peux dire que c'est lent, tout ce que tu veux. Pour 90% des systemes conventionnels, un SGBD pas optimise est deja assez performant, pour 99% des cas restants, l'optimiser suffira a resoudre tous les problemes.
alors va en urgence voir FT et dis leur qu'il sont tous des con d'avoir ecrouler leur calculateur avec oracle alors que universe ne consommait que 10% des ressourses pour la meme BDD
C'est tout à fait normal. Les SGBD traditionnels, à quelques exceptions près, n'intègrent pas d'instructions permettant de gérer les champs multivaleurs. Il faut donc passer par des bricolages immondes pour que ça marche. Le problème vient donc de la *migration*. Il suffisait de transformer la base de données de multivaluée vers relationnelle pour qu'Oracle puisse donner toute sa mesure... C'est sûr que demander à Oracle de travailler avec des bases de données MV alors qu'il n'est pas conçu pour ça, ça ne risquait pas de marcher...
(...)
"Stephane TOUGARD" <stephane@unices.org> a écrit dans le message de
(...)
Apres tu peux dire que c'est lent, tout ce que tu veux. Pour 90% des
systemes conventionnels, un SGBD pas optimise est deja assez performant,
pour 99% des cas restants, l'optimiser suffira a resoudre tous les
problemes.
alors va en urgence voir FT et dis leur qu'il sont tous des con d'avoir
ecrouler leur calculateur avec oracle alors que universe ne consommait que
10% des ressourses pour la meme BDD
C'est tout à fait normal. Les SGBD traditionnels, à quelques exceptions
près, n'intègrent pas d'instructions permettant de gérer les champs
multivaleurs. Il faut donc passer par des bricolages immondes pour que
ça marche. Le problème vient donc de la *migration*. Il suffisait de
transformer la base de données de multivaluée vers relationnelle pour
qu'Oracle puisse donner toute sa mesure...
C'est sûr que demander à Oracle de travailler avec des bases de données
MV alors qu'il n'est pas conçu pour ça, ça ne risquait pas de marcher...
"Stephane TOUGARD" a écrit dans le message de (...)
Apres tu peux dire que c'est lent, tout ce que tu veux. Pour 90% des systemes conventionnels, un SGBD pas optimise est deja assez performant, pour 99% des cas restants, l'optimiser suffira a resoudre tous les problemes.
alors va en urgence voir FT et dis leur qu'il sont tous des con d'avoir ecrouler leur calculateur avec oracle alors que universe ne consommait que 10% des ressourses pour la meme BDD
C'est tout à fait normal. Les SGBD traditionnels, à quelques exceptions près, n'intègrent pas d'instructions permettant de gérer les champs multivaleurs. Il faut donc passer par des bricolages immondes pour que ça marche. Le problème vient donc de la *migration*. Il suffisait de transformer la base de données de multivaluée vers relationnelle pour qu'Oracle puisse donner toute sa mesure... C'est sûr que demander à Oracle de travailler avec des bases de données MV alors qu'il n'est pas conçu pour ça, ça ne risquait pas de marcher...
(...)
helios
La seule chose que ca me prouve, c'est que vous avez ete incapable de migrer une bases de donnees sous Oracle. Ca demontre absolument rien d'autre.
A mon avis, c'est un probleme de competence plus que de logiciel, ne serait-ce que pour la mauvaise estimation en besoin de puissance.
le besoin de puissance etait 10 fois trop important sur universe et
insuffissant sous oracle c'est ce que tu m'explique les ingenieur de chez FT sont incompetent en base de donne c'est aussi ce que tu m'explique (c'est gentil pour les meilleurs ecole et universite d'informatique) vu le budget informatique de FT 1milliard d'euro / an depeche toi de postuler pour remplacer ces "incompetents"
La seule chose que ca me prouve, c'est que vous avez ete incapable de
migrer une bases de donnees sous Oracle. Ca demontre absolument rien
d'autre.
A mon avis, c'est un probleme de competence plus que de logiciel, ne
serait-ce que pour la mauvaise estimation en besoin de puissance.
le besoin de puissance etait 10 fois trop important sur universe et
insuffissant sous oracle c'est ce que tu m'explique
les ingenieur de chez FT sont incompetent en base de donne c'est aussi ce
que tu m'explique (c'est gentil pour les meilleurs ecole et universite
d'informatique)
vu le budget informatique de FT 1milliard d'euro / an depeche toi de
postuler pour remplacer ces "incompetents"
La seule chose que ca me prouve, c'est que vous avez ete incapable de migrer une bases de donnees sous Oracle. Ca demontre absolument rien d'autre.
A mon avis, c'est un probleme de competence plus que de logiciel, ne serait-ce que pour la mauvaise estimation en besoin de puissance.
le besoin de puissance etait 10 fois trop important sur universe et
insuffissant sous oracle c'est ce que tu m'explique les ingenieur de chez FT sont incompetent en base de donne c'est aussi ce que tu m'explique (c'est gentil pour les meilleurs ecole et universite d'informatique) vu le budget informatique de FT 1milliard d'euro / an depeche toi de postuler pour remplacer ces "incompetents"
helios
"Stephane TOUGARD" a écrit dans le message de news:
helios wrote:
avec une BDD autre que pick il ya deux coffre fort pour l'argent un dans le
bureau (BDD) et un a la banque (system) mais tous le budget de fonctionnement est dans le tiroir du directeur (donne de l'ensemble des users) et tout le monde le sait en cas d'intrusion dans le batiment a ton avis quel boite perd le plus d'argent ? a mon avis la deuxieme sauf si l'intrus est un pro , n'est pas
derange et les systemes d'alarme en panne et que l'entreprise est mal assuré (pas de sauvegarde)
Oui, mais enfin, si il y a des geraniums aux fenetres et si tu as bien gare tes radiateurs, tu avoueras que ca se tient quand meme .
ecoute un peu moins rire et chanson
"Stephane TOUGARD" <stephane@unices.org> a écrit dans le message de
news:7r8hr2-05r.ln1@gulliver.unices.org...
helios wrote:
avec une BDD autre que pick il ya deux coffre fort pour l'argent un dans
le
bureau (BDD) et un a la banque (system) mais tous le budget de
fonctionnement est dans le tiroir du directeur (donne de l'ensemble des
users) et tout le monde le sait
en cas d'intrusion dans le batiment a ton avis quel boite perd le plus
d'argent ? a mon avis la deuxieme sauf si l'intrus est un pro , n'est
pas
derange et les systemes d'alarme en panne et que l'entreprise est mal
assuré (pas de sauvegarde)
Oui, mais enfin, si il y a des geraniums aux fenetres et si tu as bien
gare tes radiateurs, tu avoueras que ca se tient quand meme .
"Stephane TOUGARD" a écrit dans le message de news:
helios wrote:
avec une BDD autre que pick il ya deux coffre fort pour l'argent un dans le
bureau (BDD) et un a la banque (system) mais tous le budget de fonctionnement est dans le tiroir du directeur (donne de l'ensemble des users) et tout le monde le sait en cas d'intrusion dans le batiment a ton avis quel boite perd le plus d'argent ? a mon avis la deuxieme sauf si l'intrus est un pro , n'est pas
derange et les systemes d'alarme en panne et que l'entreprise est mal assuré (pas de sauvegarde)
Oui, mais enfin, si il y a des geraniums aux fenetres et si tu as bien gare tes radiateurs, tu avoueras que ca se tient quand meme .
ecoute un peu moins rire et chanson
helios
"Stephane TOUGARD" a écrit dans le message de news:
helios wrote:
sauf que quand tu as le boss qui te demande une stat non prevue pour la reunion dans 10 mn tu fait comment ?
Houla, mais ca je m'en releverai jamais. Euh, je fais une petite requete SQL ? et hop j'ai mon resultat.
toi mais la secretaire elle fait comment ? elle a suivis une formation
administrateur sql et on a virer l'administrateur sql c'est ca ?
"Stephane TOUGARD" <stephane@unices.org> a écrit dans le message de
news:su8hr2-05r.ln1@gulliver.unices.org...
helios wrote:
sauf que quand tu as le boss qui te demande une stat non prevue pour la
reunion dans 10 mn tu fait comment ?
Houla, mais ca je m'en releverai jamais. Euh, je fais une petite requete
SQL ? et hop j'ai mon resultat.
toi mais la secretaire elle fait comment ? elle a suivis une formation
administrateur sql et on a virer l'administrateur sql c'est ca ?
"Stephane TOUGARD" a écrit dans le message de news:
helios wrote:
sauf que quand tu as le boss qui te demande une stat non prevue pour la reunion dans 10 mn tu fait comment ?
Houla, mais ca je m'en releverai jamais. Euh, je fais une petite requete SQL ? et hop j'ai mon resultat.
toi mais la secretaire elle fait comment ? elle a suivis une formation
administrateur sql et on a virer l'administrateur sql c'est ca ?
talon
helios wrote:
c'est vrai FT a une petite base de 60000000 de ligne telephonique qui contient malgres le MV 500 champs sans le MV cela en ferais combien de champ ?la migration vers oracle a ete un bide
Ton expertise FranceTelecom est détaillée ici par exemple? http://fr.scguild.com/usr/3957I.html http://fr.scguild.com/usr/3957R.html
helios <helios@com02.com> wrote:
c'est vrai FT a une petite base de 60000000 de ligne telephonique qui
contient malgres le MV 500 champs sans le MV cela en ferais combien de champ
?la migration vers oracle a ete un bide
Ton expertise FranceTelecom est détaillée ici par exemple?
http://fr.scguild.com/usr/3957I.html
http://fr.scguild.com/usr/3957R.html
c'est vrai FT a une petite base de 60000000 de ligne telephonique qui contient malgres le MV 500 champs sans le MV cela en ferais combien de champ ?la migration vers oracle a ete un bide
Ton expertise FranceTelecom est détaillée ici par exemple? http://fr.scguild.com/usr/3957I.html http://fr.scguild.com/usr/3957R.html
Stephane Zuckerman
le besoin de puissance etait 10 fois trop important sur universe et insuffissant sous oracle c'est ce que tu m'explique les ingenieur de chez FT sont incompetent en base de donne c'est aussi ce que tu m'explique (c'est gentil pour les meilleurs ecole et universite d'informatique)
Les "meilleures écoles" ça ne veut rien dire. Je suis dans ce qui est considéré comme une bonne école (au moins au niveau info), et je peux te dire que je connais bien meilleur que moi avec bien moins de diplômes. L'argument du "ils ont des diplômes, ils sont forcément bons" ne tient pas en informatique, *surtout* quand il s'agit d'exploitation et pas de développement.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
le besoin de puissance etait 10 fois trop important sur universe et
insuffissant sous oracle c'est ce que tu m'explique
les ingenieur de chez FT sont incompetent en base de donne c'est aussi ce
que tu m'explique (c'est gentil pour les meilleurs ecole et universite
d'informatique)
Les "meilleures écoles" ça ne veut rien dire. Je suis dans ce qui est
considéré comme une bonne école (au moins au niveau info), et je peux te
dire que je connais bien meilleur que moi avec bien moins de diplômes.
L'argument du "ils ont des diplômes, ils sont forcément bons" ne tient pas
en informatique, *surtout* quand il s'agit d'exploitation et pas de
développement.
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
le besoin de puissance etait 10 fois trop important sur universe et insuffissant sous oracle c'est ce que tu m'explique les ingenieur de chez FT sont incompetent en base de donne c'est aussi ce que tu m'explique (c'est gentil pour les meilleurs ecole et universite d'informatique)
Les "meilleures écoles" ça ne veut rien dire. Je suis dans ce qui est considéré comme une bonne école (au moins au niveau info), et je peux te dire que je connais bien meilleur que moi avec bien moins de diplômes. L'argument du "ils ont des diplômes, ils sont forcément bons" ne tient pas en informatique, *surtout* quand il s'agit d'exploitation et pas de développement.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Stephane Zuckerman
toi mais la secretaire elle fait comment ? elle a suivis une formation administrateur sql et on a virer l'administrateur sql c'est ca ? La secrétaire se sert de son appli toute graphique. Elle ne fait aucune
requête, que ce soit en SQL, en langage pour PICK, ou quoi que ce soit. Si on lui demande un truc pas prévu par l'appli, elle prend son plus beau regard bovin et elle dit qu'elle peut pas. -- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
toi mais la secretaire elle fait comment ? elle a suivis une formation
administrateur sql et on a virer l'administrateur sql c'est ca ?
La secrétaire se sert de son appli toute graphique. Elle ne fait aucune
requête, que ce soit en SQL, en langage pour PICK, ou quoi que ce soit.
Si on lui demande un truc pas prévu par l'appli, elle prend son plus beau
regard bovin et elle dit qu'elle peut pas.
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
toi mais la secretaire elle fait comment ? elle a suivis une formation administrateur sql et on a virer l'administrateur sql c'est ca ? La secrétaire se sert de son appli toute graphique. Elle ne fait aucune
requête, que ce soit en SQL, en langage pour PICK, ou quoi que ce soit. Si on lui demande un truc pas prévu par l'appli, elle prend son plus beau regard bovin et elle dit qu'elle peut pas. -- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
helios
Je bosse avec une BDD d'environ cinquante tables, sous Oracle. Les requêtes imbriquées peuvent atteindre six ou sept niveaux - et c'est déjà *énorme*. Ces six ou sept niveaux sont dûs à un besoin de s'intégrer dans le modèle existant du client pour qui nous développons notre appli. Généralement, avoir besoin de "128" niveaux d'imbrications est plus la preuve d'un mauvais design (trop compliqué) que d'une preuve d'expertise.
Evidemment, il y a des exceptions.
la norme MV est a 128 niveau la realite commercial est a 10 niveaux et en
general il y en a 4
Bref. Chez nous, tout marche au poil. Pas de temps d'attente, pas de saturation de la base.
cela marcherai mieux en MV mais a partir d'un temps de reponse satisfaisant cela ne sert a rien d'ameliorer par contre MV permetrait d'avoir un calculateur moins puissant pour le meme temps de reponse
alors va en urgence voir FT et dis leur qu'il sont tous des con d'avoir ecrouler leur calculateur avec oracle alors que universe ne consommait que
10% des ressourses pour la meme BDD
Ben s'ils ne savaient pas comment faire, ils n'étaient pas cons, juste inexpérimentés. C'est pour ça qu'on paie des gens des SSII (parfois à tort ;-) ) : parce que _eux_ sont censés savoir (je dis bien "censés").
le budget info de FT est de 1milliard d'euro /an FT a de nombreuse SSII en fillialle et en fournisseurs croit tu par exemple qu'une boite comme ATOS ORIGIN ou IBM ne connaisse pas le SQL ?ou ORACLE ? FT n'est pas une PME de 50 employer il on les moyens fincier d'avoir les meilleurs experts (quoi que .....)
[inutilité d'un dico]
sauf que quand tu as le boss qui te demande une stat non prevue pour la reunion dans 10 mn tu fait comment ?
Une stat ? Ben le plus dur dans le calcul de ta stat, c'est de trouver ta formule. Si ta base est bien conçue, la requête SQL est plutôt facile à faire généralement.
la secretaire ne connait pas sql mais la gestion et il y a pas de sqliste present il sont tous partie boire un .... cafe
Je bosse avec une BDD d'environ cinquante tables, sous Oracle. Les
requêtes imbriquées peuvent atteindre six ou sept niveaux - et c'est déjà
*énorme*. Ces six ou sept niveaux sont dûs à un besoin de s'intégrer dans
le modèle existant du client pour qui nous développons notre appli.
Généralement, avoir besoin de "128" niveaux d'imbrications est plus la
preuve d'un mauvais design (trop compliqué) que d'une preuve d'expertise.
Evidemment, il y a des exceptions.
la norme MV est a 128 niveau la realite commercial est a 10 niveaux et en
general il y en a 4
Bref. Chez nous, tout marche au poil. Pas de temps d'attente, pas de
saturation de la base.
cela marcherai mieux en MV mais a partir d'un temps de reponse satisfaisant
cela ne sert a rien d'ameliorer par contre MV permetrait d'avoir un
calculateur moins puissant pour le meme temps de reponse
alors va en urgence voir FT et dis leur qu'il sont tous des con d'avoir
ecrouler leur calculateur avec oracle alors que universe ne consommait
que
10% des ressourses pour la meme BDD
Ben s'ils ne savaient pas comment faire, ils n'étaient pas cons, juste
inexpérimentés. C'est pour ça qu'on paie des gens des SSII (parfois à tort
;-) ) : parce que _eux_ sont censés savoir (je dis bien "censés").
le budget info de FT est de 1milliard d'euro /an FT a de nombreuse SSII en
fillialle et en fournisseurs croit tu par exemple qu'une boite comme ATOS
ORIGIN ou IBM ne connaisse pas le SQL ?ou ORACLE ? FT n'est pas une PME de
50 employer il on les moyens fincier d'avoir les meilleurs experts (quoi que
.....)
[inutilité d'un dico]
sauf que quand tu as le boss qui te demande une stat non prevue pour la
reunion dans 10 mn tu fait comment ?
Une stat ? Ben le plus dur dans le calcul de ta stat, c'est de trouver ta
formule. Si ta base est bien conçue, la requête SQL est plutôt facile à
faire généralement.
la secretaire ne connait pas sql mais la gestion et il y a pas de sqliste
present il sont tous partie boire un .... cafe
Je bosse avec une BDD d'environ cinquante tables, sous Oracle. Les requêtes imbriquées peuvent atteindre six ou sept niveaux - et c'est déjà *énorme*. Ces six ou sept niveaux sont dûs à un besoin de s'intégrer dans le modèle existant du client pour qui nous développons notre appli. Généralement, avoir besoin de "128" niveaux d'imbrications est plus la preuve d'un mauvais design (trop compliqué) que d'une preuve d'expertise.
Evidemment, il y a des exceptions.
la norme MV est a 128 niveau la realite commercial est a 10 niveaux et en
general il y en a 4
Bref. Chez nous, tout marche au poil. Pas de temps d'attente, pas de saturation de la base.
cela marcherai mieux en MV mais a partir d'un temps de reponse satisfaisant cela ne sert a rien d'ameliorer par contre MV permetrait d'avoir un calculateur moins puissant pour le meme temps de reponse
alors va en urgence voir FT et dis leur qu'il sont tous des con d'avoir ecrouler leur calculateur avec oracle alors que universe ne consommait que
10% des ressourses pour la meme BDD
Ben s'ils ne savaient pas comment faire, ils n'étaient pas cons, juste inexpérimentés. C'est pour ça qu'on paie des gens des SSII (parfois à tort ;-) ) : parce que _eux_ sont censés savoir (je dis bien "censés").
le budget info de FT est de 1milliard d'euro /an FT a de nombreuse SSII en fillialle et en fournisseurs croit tu par exemple qu'une boite comme ATOS ORIGIN ou IBM ne connaisse pas le SQL ?ou ORACLE ? FT n'est pas une PME de 50 employer il on les moyens fincier d'avoir les meilleurs experts (quoi que .....)
[inutilité d'un dico]
sauf que quand tu as le boss qui te demande une stat non prevue pour la reunion dans 10 mn tu fait comment ?
Une stat ? Ben le plus dur dans le calcul de ta stat, c'est de trouver ta formule. Si ta base est bien conçue, la requête SQL est plutôt facile à faire généralement.
la secretaire ne connait pas sql mais la gestion et il y a pas de sqliste present il sont tous partie boire un .... cafe
