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
"Stanislas de Kertanguy" a écrit dans le message de news:1h0aifd.15pkch81nzgsu4N%
helios wrote:
je te conseil la lecture sur l'antropie et apres tu comprendras , en resumé
plus un individue est inteligent plus il arrives a comprendre une communication avec un taux d'antropie important .
Vous confondez *E*ntropie et alcoolémie.
Ou alors vous avez lu, à l'envers, "La théorie de l'information pour les nuls".
--
l'alcool peut creer de l'antropie la debilite aussi quel est votre cas ? les deux ?
"Stanislas de Kertanguy" <stanislas.kertanguyde@laposte.net> a écrit dans le
message de news:1h0aifd.15pkch81nzgsu4N%stanislas.kertanguyde@laposte.net...
helios <helios@com02.com> wrote:
je te conseil la lecture sur l'antropie et apres tu comprendras , en
resumé
plus un individue est inteligent plus il arrives a comprendre une
communication avec un taux d'antropie important .
Vous confondez *E*ntropie et alcoolémie.
Ou alors vous avez lu, à l'envers, "La théorie de l'information pour les
nuls".
--
l'alcool peut creer de l'antropie la debilite aussi quel est votre cas ? les
deux ?
"Stanislas de Kertanguy" a écrit dans le message de news:1h0aifd.15pkch81nzgsu4N%
helios wrote:
je te conseil la lecture sur l'antropie et apres tu comprendras , en resumé
plus un individue est inteligent plus il arrives a comprendre une communication avec un taux d'antropie important .
Vous confondez *E*ntropie et alcoolémie.
Ou alors vous avez lu, à l'envers, "La théorie de l'information pour les nuls".
--
l'alcool peut creer de l'antropie la debilite aussi quel est votre cas ? les deux ?
helios
"Stéphane CARPENTIER" a écrit dans le message de news:42e568f7$0$2967$
helios wrote:
pick sait creer les utilisateur unix ou installer un peripherique unix ce
que ne peux pas faire a ma connaissance sql
Le principe de base au niveau de la sécurité, c'est de ne pas donner plus de
droits que nécessaire.
Supposons que tu aies un serveur qui contienne un SE avec une Base De Données. Supposons qu'un pirate veuille massacrer ton serveur.
S'il réussit à trouver une faille dans ton SE et à se connecter en root, il
pourra te virer ta base de données (que ce soit pick ou Oracle), te détruire
tes disques durs, te formater ton système, etc.
S'il trouve une faille dans ta BDD qui n'est pas pick, il n'aura que les droits d'utilisateur. Il pourra supprimer toute la base de donnée, mais ses
droits s'arrêteront là.
S'il trouve une faille dans ta BDD qui est pick, il pourra supprimer toute ta base de données. Mais ce qui est grave, c'est qu'il pourra aussi effacer
tes disques durs (tu as écrit toi même qu'il sait installer un périphérique,
comme il a les droits administrateur, il pourra) et tout détruire.
Donc. Avec pick, tu multiplies par deux les possibilités d'attaque sur ton système. Au niveau sécurité, c'est très mauvais.
premierement la securite commence par des sauvegardes donc que le sgbd soit detruit ou sgbd + systeme le temp de restauration est presque le meme il est plus facile de cracker un users que le systeme sous pick cracker un users donne acces a l'users sous BDD non pick cracker un users donne acces a tout les users donc avec pick je limite les risques de vol de donnees hors ce qui est genant dans une boite c'est le vol de donnees
avec pick tout l'argent est dans un coffre fort (system +BDD) et le budget de fonctionnement repartie dans l'ensemble des tiroirs des employes (users)
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)
"Stéphane CARPENTIER" <stef.carpentier@gratuit.fr.invalid> a écrit dans le
message de news:42e568f7$0$2967$636a15ce@news.free.fr...
helios wrote:
pick sait creer les utilisateur unix ou installer un peripherique unix
ce
que ne peux pas faire a ma connaissance sql
Le principe de base au niveau de la sécurité, c'est de ne pas donner plus
de
droits que nécessaire.
Supposons que tu aies un serveur qui contienne un SE avec une Base De
Données. Supposons qu'un pirate veuille massacrer ton serveur.
S'il réussit à trouver une faille dans ton SE et à se connecter en root,
il
pourra te virer ta base de données (que ce soit pick ou Oracle), te
détruire
tes disques durs, te formater ton système, etc.
S'il trouve une faille dans ta BDD qui n'est pas pick, il n'aura que les
droits d'utilisateur. Il pourra supprimer toute la base de donnée, mais
ses
droits s'arrêteront là.
S'il trouve une faille dans ta BDD qui est pick, il pourra supprimer toute
ta base de données. Mais ce qui est grave, c'est qu'il pourra aussi
effacer
tes disques durs (tu as écrit toi même qu'il sait installer un
périphérique,
comme il a les droits administrateur, il pourra) et tout détruire.
Donc. Avec pick, tu multiplies par deux les possibilités d'attaque sur ton
système. Au niveau sécurité, c'est très mauvais.
premierement la securite commence par des sauvegardes donc que le sgbd soit
detruit ou sgbd + systeme le temp de restauration est presque le meme
il est plus facile de cracker un users que le systeme sous pick cracker un
users donne acces a l'users sous BDD non pick cracker un users donne acces a
tout les users
donc avec pick je limite les risques de vol de donnees hors ce qui est
genant dans une boite c'est le vol de donnees
avec pick tout l'argent est dans un coffre fort (system +BDD) et le budget
de fonctionnement repartie dans l'ensemble des tiroirs des employes (users)
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)
"Stéphane CARPENTIER" a écrit dans le message de news:42e568f7$0$2967$
helios wrote:
pick sait creer les utilisateur unix ou installer un peripherique unix ce
que ne peux pas faire a ma connaissance sql
Le principe de base au niveau de la sécurité, c'est de ne pas donner plus de
droits que nécessaire.
Supposons que tu aies un serveur qui contienne un SE avec une Base De Données. Supposons qu'un pirate veuille massacrer ton serveur.
S'il réussit à trouver une faille dans ton SE et à se connecter en root, il
pourra te virer ta base de données (que ce soit pick ou Oracle), te détruire
tes disques durs, te formater ton système, etc.
S'il trouve une faille dans ta BDD qui n'est pas pick, il n'aura que les droits d'utilisateur. Il pourra supprimer toute la base de donnée, mais ses
droits s'arrêteront là.
S'il trouve une faille dans ta BDD qui est pick, il pourra supprimer toute ta base de données. Mais ce qui est grave, c'est qu'il pourra aussi effacer
tes disques durs (tu as écrit toi même qu'il sait installer un périphérique,
comme il a les droits administrateur, il pourra) et tout détruire.
Donc. Avec pick, tu multiplies par deux les possibilités d'attaque sur ton système. Au niveau sécurité, c'est très mauvais.
premierement la securite commence par des sauvegardes donc que le sgbd soit detruit ou sgbd + systeme le temp de restauration est presque le meme il est plus facile de cracker un users que le systeme sous pick cracker un users donne acces a l'users sous BDD non pick cracker un users donne acces a tout les users donc avec pick je limite les risques de vol de donnees hors ce qui est genant dans une boite c'est le vol de donnees
avec pick tout l'argent est dans un coffre fort (system +BDD) et le budget de fonctionnement repartie dans l'ensemble des tiroirs des employes (users)
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)
helios
"Michel Talon" a écrit dans le message de news:dc4pgl$1b75$
Thierry Thomas wrote:
Je croyais que access c'était la base que Microsoft a achetée à Sybase,
auquel cas elle serait du même niveau de qualité que Oracle.
C'est MS-SQL Server qui provient de Sybase (je crois que la version 10.0.x de Sybase correspondait exactement à MS SQL 4.x). Le langage
Ah bon, je n'avais pas rêvé! Evidemment je parlais du serveur de base de données de Microsoft.
Quoiqu'il en soit, Sybase a toujours été à la traine par rapport à Oracle...
Je n'ai pas entendu dire ça. J'ai entendu dire que Oracle était surtout trés fort pour vendre des produits non encore développés.
comme microsoft d'ailleur
"Michel Talon" <talon@lpthe.jussieu.fr> a écrit dans le message de
news:dc4pgl$1b75$2@asmodee.lpthe.jussieu.fr...
Thierry Thomas <tthomas@mail.dotcom.fr> wrote:
Je croyais que access c'était la base que Microsoft a achetée à
Sybase,
auquel cas elle serait du même niveau de qualité que Oracle.
C'est MS-SQL Server qui provient de Sybase (je crois que la version
10.0.x de Sybase correspondait exactement à MS SQL 4.x). Le langage
Ah bon, je n'avais pas rêvé! Evidemment je parlais du serveur de base de
données de Microsoft.
Quoiqu'il en soit, Sybase a toujours été à la traine par rapport à
Oracle...
Je n'ai pas entendu dire ça. J'ai entendu dire que Oracle était surtout
trés fort pour vendre des produits non encore développés.
"Michel Talon" a écrit dans le message de news:dc4pgl$1b75$
Thierry Thomas wrote:
Je croyais que access c'était la base que Microsoft a achetée à Sybase,
auquel cas elle serait du même niveau de qualité que Oracle.
C'est MS-SQL Server qui provient de Sybase (je crois que la version 10.0.x de Sybase correspondait exactement à MS SQL 4.x). Le langage
Ah bon, je n'avais pas rêvé! Evidemment je parlais du serveur de base de données de Microsoft.
Quoiqu'il en soit, Sybase a toujours été à la traine par rapport à Oracle...
Je n'ai pas entendu dire ça. J'ai entendu dire que Oracle était surtout trés fort pour vendre des produits non encore développés.
comme microsoft d'ailleur
Stephane TOUGARD
helios wrote:
Ho, j'ai compris, Pick n'est pas multi-utilisateur, chaque utilisateur a ses fichiers comme Unix et l'acces multi-utilisateur est gere par un systeme de securite type ACL.
t'as encore rien compris chaque utilisateur a des droit sur des fichier et appli pas sur tout la base de donne ainsi pourquoi un commercial aurait il acces a la gestion fournisseur complete ou au fiche de paye , pourquoi le technicien paye a la gestion ....avec oracle il suffit de craque le
Euh ... c'est tres exactement ce que j'ai marque.
-- 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:
Ho, j'ai compris, Pick n'est pas multi-utilisateur, chaque utilisateur a
ses fichiers comme Unix et l'acces multi-utilisateur est gere par un
systeme de securite type ACL.
t'as encore rien compris chaque utilisateur a des droit sur des fichier et
appli pas sur tout la base de donne ainsi pourquoi un commercial aurait il
acces a la gestion fournisseur complete ou au fiche de paye , pourquoi le
technicien paye a la gestion ....avec oracle il suffit de craque le
Euh ... c'est tres exactement ce que j'ai marque.
--
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
Ho, j'ai compris, Pick n'est pas multi-utilisateur, chaque utilisateur a ses fichiers comme Unix et l'acces multi-utilisateur est gere par un systeme de securite type ACL.
t'as encore rien compris chaque utilisateur a des droit sur des fichier et appli pas sur tout la base de donne ainsi pourquoi un commercial aurait il acces a la gestion fournisseur complete ou au fiche de paye , pourquoi le technicien paye a la gestion ....avec oracle il suffit de craque le
Euh ... c'est tres exactement ce que j'ai marque.
-- 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
Stephane TOUGARD
helios wrote:
Tout comme pick, il suffit de planter le process commun. Sauf que pick tourne en root.
la difference est que pick etant sous root il est vraiment securise et un plantage pick plante root en general donc ...
Il faudrait faire une liste des meilleurs neuneuteries de l'admin Unix, tu pourrais la remplir en grande partie a toi tout seul.
oracle ne tient pas la route fasse a universe peut importe ou est le manque de performance, essais de remplacement fait en 2002 , oracle a ecroule les calculateur la ou universe utilise meme pas 10% de la puissance de calcul
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.
plutot c'est moi qui me suis fait chier car cela n'a rien d'interressant comme job et pourtant j'avait automatiser pas mal de taches merdique de securite locale (personne ne voulait faire ce boulot de con par contre cela m'a permis d'avoir de nombreuse formation de mon choix)
Et t'as pas demande "orthographe" ?
-- 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:
Tout comme pick, il suffit de planter le process commun. Sauf que pick
tourne en root.
la difference est que pick etant sous root il est vraiment securise et un
plantage pick plante root en general donc ...
Il faudrait faire une liste des meilleurs neuneuteries de l'admin Unix,
tu pourrais la remplir en grande partie a toi tout seul.
oracle ne tient pas la route fasse a universe peut importe ou est le manque
de performance, essais de remplacement fait en 2002 , oracle a ecroule les
calculateur la ou universe utilise meme pas 10% de la puissance de calcul
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.
plutot c'est moi qui me suis fait chier car cela n'a rien d'interressant
comme job et pourtant j'avait automatiser pas mal de taches merdique de
securite locale (personne ne voulait faire ce boulot de con par contre cela
m'a permis d'avoir de nombreuse formation de mon choix)
Et t'as pas demande "orthographe" ?
--
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
Tout comme pick, il suffit de planter le process commun. Sauf que pick tourne en root.
la difference est que pick etant sous root il est vraiment securise et un plantage pick plante root en general donc ...
Il faudrait faire une liste des meilleurs neuneuteries de l'admin Unix, tu pourrais la remplir en grande partie a toi tout seul.
oracle ne tient pas la route fasse a universe peut importe ou est le manque de performance, essais de remplacement fait en 2002 , oracle a ecroule les calculateur la ou universe utilise meme pas 10% de la puissance de calcul
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.
plutot c'est moi qui me suis fait chier car cela n'a rien d'interressant comme job et pourtant j'avait automatiser pas mal de taches merdique de securite locale (personne ne voulait faire ce boulot de con par contre cela m'a permis d'avoir de nombreuse formation de mon choix)
Et t'as pas demande "orthographe" ?
-- 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
"Stephane TOUGARD" a écrit dans le message de news:
helios wrote:
Ah c'est ca le multi-valeurs. C'est tout con a faire avec n'importe quelle SGBD, c'est juste une histoire d'index qui relie deux tables.
Ensuite les donnees avec des requetes imbriquees, rien de bien complique dans tout cela.
Tu veux dire que chaque valeur dans une entree correspond chacune a plusieurs valeurs ?
Parce que si tu veux, des valeurs derriere un index, je t'en mets quelques centaines de milliers, chacune avec plusieurs definitions, ca me pose pas vraiment un probleme et ca sera tres performant.
le probleme est pas de le faire sur un niveau mais sur 128 niveau
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
Un dico etait utile a l'epoque ou la secretaire accedait directement au mainframe, mais ce temps est revolu et la secretaire ne construit meme pas des requetes, elle clique sur le bouton "Chercher Client", elle donne les infos et elle a son client.
sauf que quand tu as le boss qui te demande une stat non prevue pour la reunion dans 10 mn tu fait comment ?
-- 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
"Stephane TOUGARD" <stephane@unices.org> a écrit dans le message de
news:hkagr2-g8o.ln1@gulliver.unices.org...
helios wrote:
Ah c'est ca le multi-valeurs. C'est tout con a faire avec n'importe
quelle SGBD, c'est juste une histoire d'index qui relie deux tables.
Ensuite les donnees avec des requetes imbriquees, rien de bien complique
dans tout cela.
Tu veux dire que chaque valeur dans une entree correspond chacune a
plusieurs valeurs ?
Parce que si tu veux, des valeurs derriere un index, je t'en mets
quelques centaines de milliers, chacune avec plusieurs definitions, ca
me pose pas vraiment un probleme et ca sera tres performant.
le probleme est pas de le faire sur un niveau mais sur 128 niveau
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
Un dico etait utile a l'epoque ou la secretaire accedait directement au
mainframe, mais ce temps est revolu et la secretaire ne construit meme
pas des requetes, elle clique sur le bouton "Chercher Client", elle
donne les infos et elle a son client.
sauf que quand tu as le boss qui te demande une stat non prevue pour la
reunion dans 10 mn tu fait comment ?
--
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
"Stephane TOUGARD" a écrit dans le message de news:
helios wrote:
Ah c'est ca le multi-valeurs. C'est tout con a faire avec n'importe quelle SGBD, c'est juste une histoire d'index qui relie deux tables.
Ensuite les donnees avec des requetes imbriquees, rien de bien complique dans tout cela.
Tu veux dire que chaque valeur dans une entree correspond chacune a plusieurs valeurs ?
Parce que si tu veux, des valeurs derriere un index, je t'en mets quelques centaines de milliers, chacune avec plusieurs definitions, ca me pose pas vraiment un probleme et ca sera tres performant.
le probleme est pas de le faire sur un niveau mais sur 128 niveau
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
Un dico etait utile a l'epoque ou la secretaire accedait directement au mainframe, mais ce temps est revolu et la secretaire ne construit meme pas des requetes, elle clique sur le bouton "Chercher Client", elle donne les infos et elle a son client.
sauf que quand tu as le boss qui te demande une stat non prevue pour la reunion dans 10 mn tu fait comment ?
-- 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
Pas vraiment. Avec un SGBDR, on peut éviter cette redondance en définissant deux tables comme suit: Table 1 ID NOM 01 Jerome 02 Remy
et en définissant la relation kivabien entre les ID de chaque table. C'est un peu grossier comme exemple, mais si tu imagines qu'on multiplie les infos dans la table 1 (nom de famille, date de naissance, que sais-je encore), ces infos ne sont bien présentes qu'une seule fois. C'est d'ailleurs la raison d'être des SGBDR.
la tu as deux table pour un MV de niveau 2 tu envisage 128 tables pour un MV de niveau 128?
En conclusion, autant le système MV peut être intéressant pour une personne ne désirant pas se plonger dans les SGBDR vu la petite taille de la base gérée (cas typique: une fiche d'identité où on veut pouvoir encoder autant de numéro de téléphone qu'on veut sans multiplier les champs à gogo), autant quelqu'un qui doit gérer de grosses bases aura un meilleur aperçu de ce qu'il fait en utilisant un SGBDR. Et puis, si les bases de données multivaluées étaient si indispensable et si performantes que tu le prétends, je crois que ça se saurait... ;-)
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
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
Pas vraiment. Avec un SGBDR, on peut éviter cette redondance en
définissant deux tables comme suit:
Table 1
ID NOM
01 Jerome
02 Remy
et en définissant la relation kivabien entre les ID de chaque table.
C'est un peu grossier comme exemple, mais si tu imagines qu'on multiplie
les infos dans la table 1 (nom de famille, date de naissance, que
sais-je encore), ces infos ne sont bien présentes qu'une seule fois.
C'est d'ailleurs la raison d'être des SGBDR.
la tu as deux table pour un MV de niveau 2 tu envisage 128 tables pour un MV
de niveau 128?
En conclusion, autant le système MV peut être intéressant pour une
personne ne désirant pas se plonger dans les SGBDR vu la petite taille
de la base gérée (cas typique: une fiche d'identité où on veut pouvoir
encoder autant de numéro de téléphone qu'on veut sans multiplier les
champs à gogo), autant quelqu'un qui doit gérer de grosses bases aura un
meilleur aperçu de ce qu'il fait en utilisant un SGBDR. Et puis, si les
bases de données multivaluées étaient si indispensable et si
performantes que tu le prétends, je crois que ça se saurait... ;-)
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
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
et en définissant la relation kivabien entre les ID de chaque table. C'est un peu grossier comme exemple, mais si tu imagines qu'on multiplie les infos dans la table 1 (nom de famille, date de naissance, que sais-je encore), ces infos ne sont bien présentes qu'une seule fois. C'est d'ailleurs la raison d'être des SGBDR.
la tu as deux table pour un MV de niveau 2 tu envisage 128 tables pour un MV de niveau 128?
En conclusion, autant le système MV peut être intéressant pour une personne ne désirant pas se plonger dans les SGBDR vu la petite taille de la base gérée (cas typique: une fiche d'identité où on veut pouvoir encoder autant de numéro de téléphone qu'on veut sans multiplier les champs à gogo), autant quelqu'un qui doit gérer de grosses bases aura un meilleur aperçu de ce qu'il fait en utilisant un SGBDR. Et puis, si les bases de données multivaluées étaient si indispensable et si performantes que tu le prétends, je crois que ça se saurait... ;-)
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
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
Stephane TOUGARD
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 .
-- 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:
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 .
--
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
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 .
-- 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
Stephane TOUGARD
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.
-- 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:
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.
--
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
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.
-- 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
Stephane Zuckerman
Parce que si tu veux, des valeurs derriere un index, je t'en mets quelques centaines de milliers, chacune avec plusieurs definitions, ca me pose pas vraiment un probleme et ca sera tres performant.
le probleme est pas de le faire sur un niveau mais sur 128 niveau
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.
Bref. Chez nous, tout marche au poil. Pas de temps d'attente, pas de saturation de la base.
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
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").
[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.
-- "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)
Parce que si tu veux, des valeurs derriere un index, je t'en mets
quelques centaines de milliers, chacune avec plusieurs definitions, ca
me pose pas vraiment un probleme et ca sera tres performant.
le probleme est pas de le faire sur un niveau mais sur 128 niveau
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.
Bref. Chez nous, tout marche au poil. Pas de temps d'attente, pas de
saturation de la base.
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
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").
[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.
--
"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)
Parce que si tu veux, des valeurs derriere un index, je t'en mets quelques centaines de milliers, chacune avec plusieurs definitions, ca me pose pas vraiment un probleme et ca sera tres performant.
le probleme est pas de le faire sur un niveau mais sur 128 niveau
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.
Bref. Chez nous, tout marche au poil. Pas de temps d'attente, pas de saturation de la base.
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
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").
[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.
-- "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)
