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
helios doit etre le seul a comprendre ce que j'ai ecrit, parce que meme moi je comprends pas. Je crois que ce type vient d'une autre planete et parle 32000 dialectes.
Il est multivalué, c'est pour ça.
:-D
helios doit etre le seul a comprendre ce que j'ai ecrit, parce que meme
moi je comprends pas. Je crois que ce type vient d'une autre planete et
parle 32000 dialectes.
helios doit etre le seul a comprendre ce que j'ai ecrit, parce que meme moi je comprends pas. Je crois que ce type vient d'une autre planete et parle 32000 dialectes.
Il est multivalué, c'est pour ça.
:-D
Vincent Bernat
OoO Pendant le journal télévisé du lundi 25 juillet 2005, vers 20:48, "helios" disait:
en matiere de securite je vous signale que la securite local d'un centre de calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs et 25 serveurs repartie sur toute la france alors si je vous dit que pick est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd etait de maniere marginal dans mon parc )
Moi, j'ai été agent secret. -- panic("CPU too expensive - making holiday in the ANDES!"); 2.2.16 /usr/src/linux/arch/mips/kernel/traps.c
OoO Pendant le journal télévisé du lundi 25 juillet 2005, vers 20:48,
"helios" <helios@com02.com> disait:
en matiere de securite je vous signale que la securite local d'un centre de
calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs
et 25 serveurs repartie sur toute la france alors si je vous dit que pick
est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd
etait de maniere marginal dans mon parc )
Moi, j'ai été agent secret.
--
panic("CPU too expensive - making holiday in the ANDES!");
2.2.16 /usr/src/linux/arch/mips/kernel/traps.c
OoO Pendant le journal télévisé du lundi 25 juillet 2005, vers 20:48, "helios" disait:
en matiere de securite je vous signale que la securite local d'un centre de calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs et 25 serveurs repartie sur toute la france alors si je vous dit que pick est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd etait de maniere marginal dans mon parc )
Moi, j'ai été agent secret. -- panic("CPU too expensive - making holiday in the ANDES!"); 2.2.16 /usr/src/linux/arch/mips/kernel/traps.c
Vincent Bernat
OoO Pendant le journal télévisé du lundi 25 juillet 2005, vers 20:53, "helios" disait:
essais deja www.pick.com02.com et il y en a d'autre
Je parlais de liens serieux.
quel critere te permet de juger ce lien non serieux ?
Que l'on ne peut être juge et partie ? A moins que ce soit le fait que la page a été créée avec Frontpage. Ou la musique en fond ? Ou les GIFs animés ? Mystère. -- if (user_specified) /* Didn't work, but the user is convinced this is the * place. */ 2.4.0-test2 /usr/src/linux/drivers/parport/parport_pc.c
OoO Pendant le journal télévisé du lundi 25 juillet 2005, vers 20:53,
"helios" <helios@com02.com> disait:
essais deja www.pick.com02.com et il y en a d'autre
Je parlais de liens serieux.
quel critere te permet de juger ce lien non serieux ?
Que l'on ne peut être juge et partie ? A moins que ce soit le fait que
la page a été créée avec Frontpage. Ou la musique en fond ? Ou les
GIFs animés ? Mystère.
--
if (user_specified)
/* Didn't work, but the user is convinced this is the
* place. */
2.4.0-test2 /usr/src/linux/drivers/parport/parport_pc.c
OoO Pendant le journal télévisé du lundi 25 juillet 2005, vers 20:53, "helios" disait:
essais deja www.pick.com02.com et il y en a d'autre
Je parlais de liens serieux.
quel critere te permet de juger ce lien non serieux ?
Que l'on ne peut être juge et partie ? A moins que ce soit le fait que la page a été créée avec Frontpage. Ou la musique en fond ? Ou les GIFs animés ? Mystère. -- if (user_specified) /* Didn't work, but the user is convinced this is the * place. */ 2.4.0-test2 /usr/src/linux/drivers/parport/parport_pc.c
helios
Par exemple, pour un log de connexion et un SGBD traditionnel, on aurait
ID NOM CONNEXION 01 Jerome 12:30 02 Remy 12:45 03 Jerome 13:20 04 Remy 13:45
et avec un SGBD multivalué:
ID NOM CONNEXIONS 01 Jerome 12:30;13:20 02 Remy 12:45;13:45
Ca fait un peu gagne-petit, surtout vu les tailles des disques actuels, et on peut arriver au même résultat en créant des tables liées dans un SGBDR, d'où le fait que ce genre de bases soit en perte de vitesse.
c'est gagne petit sur un niveau mais sur 4 niveaux c'est deja beaucoup plus interessant imagine que chaque niveau a 10 valeurs 4 niveaux te donne 10000 comme rapport entre le relationnel et le mv la norme mv est defini sur 128 niveaux
a condition que le dico cela soit CONNEXIONS
je cherche dans le dico connexion 13:20 et je tombe sur id 01 qui donne Jerome
Voilà. Et dans le cas où on a ID NOM CONNEXIONS 01 Jerome 12:30;13:20;14:00 02 Remy 12:45;13:45;14:00
Si je cherche 14:00, ça me renvoit id 01 Jerome et id 02 Remy. L'avantage dans ce cas est que je ne dois pas "tronconner" moi-même la chaîne de caractère "CONNEXIONS", le système le faisant à ma place...
l'interro en pick est :
LISTER fichier AVEC CONNEXION = "14:00" NOM
resultat :
JEROME REMY
et comment je fais si je veux toutes les connexions de Jerome il faut que je cree un autre dico ?
pour ca l'interro serait
LISTER fichier AVEC NOM = "Jerome" CONNEXION
resultat:
Jerome 12:30 13:20 14:00
Non. Le dictionnaire ne porte que sur la rubrique mutlivaluée, en l'occurence CONNEXIONS. Les reste s'interroge via des systèmes classiques.
le dico porte sur tout :
dans l'exemple le dico contient un article NOM et un article CONNEXION
la modelisation par contre n'est pas bonne en mv l'id ne serait serait le nom qui servirait de clef car un id numerique serait inutile contrairement au relationnel car le nom est une clef unique ce qui donne :
NOM CONNEXIONS Jerome 12:30;13:20;14:00 Remy 12:45;13:45;14:00
et si le fichier de connexion doit contenir les noms fichier ouvert et les articles de fichier modifier imagine le modele en relationnelle et en mv tu comprendra l'avantage du mv par rapport au relationnel
si il y a trois fichiers par connexion et trois article par fichier le relationnel aura besoin de 54 lignes pour definir le modele mv n'auras que 2 lignes
Par exemple, pour un log de connexion et un SGBD traditionnel, on
aurait
ID NOM CONNEXION
01 Jerome 12:30
02 Remy 12:45
03 Jerome 13:20
04 Remy 13:45
et avec un SGBD multivalué:
ID NOM CONNEXIONS
01 Jerome 12:30;13:20
02 Remy 12:45;13:45
Ca fait un peu gagne-petit, surtout vu les tailles des disques
actuels, et on peut arriver au même résultat en créant des tables
liées dans un SGBDR, d'où le fait que ce genre de bases soit en perte
de vitesse.
c'est gagne petit sur un niveau mais sur 4 niveaux c'est deja beaucoup plus
interessant imagine que chaque niveau a 10 valeurs 4 niveaux te donne 10000
comme rapport entre le relationnel et le mv la norme mv est defini sur 128
niveaux
a condition que le dico cela soit CONNEXIONS
je cherche dans le dico connexion 13:20 et je tombe sur id 01 qui donne
Jerome
Voilà. Et dans le cas où on a
ID NOM CONNEXIONS
01 Jerome 12:30;13:20;14:00
02 Remy 12:45;13:45;14:00
Si je cherche 14:00, ça me renvoit id 01 Jerome et id 02 Remy.
L'avantage dans ce cas est que je ne dois pas "tronconner" moi-même la
chaîne de caractère "CONNEXIONS", le système le faisant à ma place...
l'interro en pick est :
LISTER fichier AVEC CONNEXION = "14:00" NOM
resultat :
JEROME
REMY
et comment je fais si je veux toutes les connexions de Jerome
il faut que je cree un autre dico ?
pour ca l'interro serait
LISTER fichier AVEC NOM = "Jerome" CONNEXION
resultat:
Jerome 12:30
13:20
14:00
Non. Le dictionnaire ne porte que sur la rubrique mutlivaluée, en
l'occurence CONNEXIONS. Les reste s'interroge via des systèmes classiques.
le dico porte sur tout :
dans l'exemple le dico contient un article NOM et un article CONNEXION
la modelisation par contre n'est pas bonne en mv l'id ne serait serait le
nom qui servirait de clef car un id numerique serait inutile contrairement
au relationnel car le nom est une clef unique
ce qui donne :
NOM CONNEXIONS
Jerome 12:30;13:20;14:00
Remy 12:45;13:45;14:00
et si le fichier de connexion doit contenir les noms fichier ouvert et les
articles de fichier modifier imagine le modele en relationnelle et en mv tu
comprendra l'avantage du mv par rapport au relationnel
si il y a trois fichiers par connexion et trois article par fichier le
relationnel aura besoin de 54 lignes pour definir le modele mv n'auras que 2
lignes
Par exemple, pour un log de connexion et un SGBD traditionnel, on aurait
ID NOM CONNEXION 01 Jerome 12:30 02 Remy 12:45 03 Jerome 13:20 04 Remy 13:45
et avec un SGBD multivalué:
ID NOM CONNEXIONS 01 Jerome 12:30;13:20 02 Remy 12:45;13:45
Ca fait un peu gagne-petit, surtout vu les tailles des disques actuels, et on peut arriver au même résultat en créant des tables liées dans un SGBDR, d'où le fait que ce genre de bases soit en perte de vitesse.
c'est gagne petit sur un niveau mais sur 4 niveaux c'est deja beaucoup plus interessant imagine que chaque niveau a 10 valeurs 4 niveaux te donne 10000 comme rapport entre le relationnel et le mv la norme mv est defini sur 128 niveaux
a condition que le dico cela soit CONNEXIONS
je cherche dans le dico connexion 13:20 et je tombe sur id 01 qui donne Jerome
Voilà. Et dans le cas où on a ID NOM CONNEXIONS 01 Jerome 12:30;13:20;14:00 02 Remy 12:45;13:45;14:00
Si je cherche 14:00, ça me renvoit id 01 Jerome et id 02 Remy. L'avantage dans ce cas est que je ne dois pas "tronconner" moi-même la chaîne de caractère "CONNEXIONS", le système le faisant à ma place...
l'interro en pick est :
LISTER fichier AVEC CONNEXION = "14:00" NOM
resultat :
JEROME REMY
et comment je fais si je veux toutes les connexions de Jerome il faut que je cree un autre dico ?
pour ca l'interro serait
LISTER fichier AVEC NOM = "Jerome" CONNEXION
resultat:
Jerome 12:30 13:20 14:00
Non. Le dictionnaire ne porte que sur la rubrique mutlivaluée, en l'occurence CONNEXIONS. Les reste s'interroge via des systèmes classiques.
le dico porte sur tout :
dans l'exemple le dico contient un article NOM et un article CONNEXION
la modelisation par contre n'est pas bonne en mv l'id ne serait serait le nom qui servirait de clef car un id numerique serait inutile contrairement au relationnel car le nom est une clef unique ce qui donne :
NOM CONNEXIONS Jerome 12:30;13:20;14:00 Remy 12:45;13:45;14:00
et si le fichier de connexion doit contenir les noms fichier ouvert et les articles de fichier modifier imagine le modele en relationnelle et en mv tu comprendra l'avantage du mv par rapport au relationnel
si il y a trois fichiers par connexion et trois article par fichier le relationnel aura besoin de 54 lignes pour definir le modele mv n'auras que 2 lignes
Philippe Lebon
helios wrote:
en matiere de securite je vous signale que la securite local d'un centre de calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs et 25 serveurs repartie sur toute la france alors si je vous dit que pick est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd etait de maniere marginal dans mon parc )
Vous pourriez le refaire en 4 lignes ?
-- Ravis que son coutelas lui ait désigné le soleil levant, Rahan s'élança vers ce nouvel horizon. Lui non plus n'oublierait pas ce clan ou il n'avait rencontré ni chasseurs hostiles, ni chef orgueuilleux, ni sorcier stupide, ce qui en ces temps farouches etait fort rare chez ceux-qui-marchent-debout.
helios wrote:
en matiere de securite je vous signale que la securite local d'un centre de
calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs
et 25 serveurs repartie sur toute la france alors si je vous dit que pick
est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd
etait de maniere marginal dans mon parc )
Vous pourriez le refaire en 4 lignes ?
--
Ravis que son coutelas lui ait désigné le soleil levant, Rahan s'élança vers
ce nouvel horizon. Lui non plus n'oublierait pas ce clan ou il n'avait
rencontré ni chasseurs hostiles, ni chef orgueuilleux, ni sorcier stupide, ce
qui en ces temps farouches etait fort rare chez ceux-qui-marchent-debout.
en matiere de securite je vous signale que la securite local d'un centre de calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs et 25 serveurs repartie sur toute la france alors si je vous dit que pick est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd etait de maniere marginal dans mon parc )
Vous pourriez le refaire en 4 lignes ?
-- Ravis que son coutelas lui ait désigné le soleil levant, Rahan s'élança vers ce nouvel horizon. Lui non plus n'oublierait pas ce clan ou il n'avait rencontré ni chasseurs hostiles, ni chef orgueuilleux, ni sorcier stupide, ce qui en ces temps farouches etait fort rare chez ceux-qui-marchent-debout.
Philippe Lebon
Vincent Bernat wrote:
OoO Pendant le journal télévisé du lundi 25 juillet 2005, vers 20:48, "helios" disait:
en matiere de securite je vous signale que la securite local d'un centre de calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs et 25 serveurs repartie sur toute la france alors si je vous dit que pick est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd etait de maniere marginal dans mon parc )
Moi, j'ai été agent secret.
Et moi cosmonaute.
-- Si le fils de Craô restait à l'écart, c'est qu'il n'intervenait jamais quand ceux-qui-marchent-debout decidaient de leur destin. Mais il fût heureux de voir Trao venir à lui, les bras fraternellement tendus. Il attendit l'accolade tandis que les clameurs de ceux qui ne mourraient plus en chassant le feux, couvraient le tonnerre d'un lointain volcan.
Vincent Bernat wrote:
OoO Pendant le journal télévisé du lundi 25 juillet 2005, vers 20:48,
"helios" <helios@com02.com> disait:
en matiere de securite je vous signale que la securite local d'un centre de
calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs
et 25 serveurs repartie sur toute la france alors si je vous dit que pick
est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd
etait de maniere marginal dans mon parc )
Moi, j'ai été agent secret.
Et moi cosmonaute.
--
Si le fils de Craô restait à l'écart, c'est qu'il n'intervenait jamais quand
ceux-qui-marchent-debout decidaient de leur destin. Mais il fût heureux de
voir Trao venir à lui, les bras fraternellement tendus. Il attendit
l'accolade tandis que les clameurs de ceux qui ne mourraient plus en chassant
le feux, couvraient le tonnerre d'un lointain volcan.
OoO Pendant le journal télévisé du lundi 25 juillet 2005, vers 20:48, "helios" disait:
en matiere de securite je vous signale que la securite local d'un centre de calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs et 25 serveurs repartie sur toute la france alors si je vous dit que pick est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd etait de maniere marginal dans mon parc )
Moi, j'ai été agent secret.
Et moi cosmonaute.
-- Si le fils de Craô restait à l'écart, c'est qu'il n'intervenait jamais quand ceux-qui-marchent-debout decidaient de leur destin. Mais il fût heureux de voir Trao venir à lui, les bras fraternellement tendus. Il attendit l'accolade tandis que les clameurs de ceux qui ne mourraient plus en chassant le feux, couvraient le tonnerre d'un lointain volcan.
Miod Vallat
Moi, j'ai été agent secret.
Et moi cosmonaute.
Avant ou apres ta carriere de J2EE lead architect ?
Moi, j'ai été agent secret.
Et moi cosmonaute.
Avant ou apres ta carriere de J2EE lead architect ?
Avant ou apres ta carriere de J2EE lead architect ?
Nicolas Le Scouarnec
j'ai une damn ssmall linux qui tourne sur un vieux portable 233 et 40 MO de disque (enfin 7 d'occupé)... je peux te faire un dd si tu veux ... comme c'est ue deb, tu pourras te debrouiller pour les header, s'ils n'y ont pas deja ...
Oula, mais 40 Mo, je veux un compilateur, Xorg, FluxBox et image. J'ai opté pour une jolie Gentoo, ca s'installe vite, sans trop de problème meme sur un vieux portable. J'aurais juste voulu un stage4 ou 5 pour que ca aille encore plus vite...
-- Nicolas Le Scouarnec
j'ai une damn ssmall linux qui tourne sur un vieux portable 233 et 40 MO de
disque (enfin 7 d'occupé)... je peux te faire un dd si tu veux ... comme
c'est ue deb, tu pourras te debrouiller pour les header, s'ils n'y ont pas
deja ...
Oula, mais 40 Mo, je veux un compilateur, Xorg, FluxBox et image. J'ai
opté pour une jolie Gentoo, ca s'installe vite, sans trop de problème
meme sur un vieux portable. J'aurais juste voulu un stage4 ou 5 pour
que ca aille encore plus vite...
j'ai une damn ssmall linux qui tourne sur un vieux portable 233 et 40 MO de disque (enfin 7 d'occupé)... je peux te faire un dd si tu veux ... comme c'est ue deb, tu pourras te debrouiller pour les header, s'ils n'y ont pas deja ...
Oula, mais 40 Mo, je veux un compilateur, Xorg, FluxBox et image. J'ai opté pour une jolie Gentoo, ca s'installe vite, sans trop de problème meme sur un vieux portable. J'aurais juste voulu un stage4 ou 5 pour que ca aille encore plus vite...
-- Nicolas Le Scouarnec
Jerome Lambert
Par exemple, pour un log de connexion et un SGBD traditionnel, on aurait ID NOM CONNEXION 01 Jerome 12:30 02 Remy 12:45 03 Jerome 13:20 04 Remy 13:45
et avec un SGBD multivalué:
ID NOM CONNEXIONS 01 Jerome 12:30;13:20 02 Remy 12:45;13:45
Ca fait un peu gagne-petit, surtout vu les tailles des disques actuels, et on peut arriver au même résultat en créant des tables liées dans un SGBDR, d'où le fait que ce genre de bases soit en perte de vitesse.
c'est gagne petit sur un niveau mais sur 4 niveaux c'est deja beaucoup plus interessant imagine que chaque niveau a 10 valeurs 4 niveaux te donne 10000 comme rapport entre le relationnel et le mv la norme mv est defini sur 128 niveaux
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.
Si je cherche 14:00, ça me renvoit id 01 Jerome et id 02 Remy. L'avantage dans ce cas est que je ne dois pas "tronconner" moi-même la chaîne de caractère "CONNEXIONS", le système le faisant à ma place...
l'interro en pick est :
LISTER fichier AVEC CONNEXION = "14:00" NOM
resultat :
JEROME REMY
Et j'obtiens le même resultat en demandant les noms correspondants à la connexion 14:00, qui se traduit en SQL (dixit Access) par
SELECT Table1.Nom FROM Table1 RIGHT JOIN Table2 ON Table1.Id = Table2.Id WHERE ((Table2.Connexions)=#14:00#);
et comment je fais si je veux toutes les connexions de Jerome il faut que je cree un autre dico ?
pour ca l'interro serait
LISTER fichier AVEC NOM = "Jerome" CONNEXION
resultat:
Jerome 12:30 13:20 14:00
Même topo: j'affiche les heures correspondantes au critère "Jérôme" porté sur le nom. La traduction SQL est
SELECT Table2.Connexions FROM Table1 RIGHT JOIN Table2 ON Table1.Id = Table2.Id WHERE ((Table1.Nom)="Jerome");
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... ;-)
Par exemple, pour un log de connexion et un SGBD traditionnel, on
aurait
ID NOM CONNEXION
01 Jerome 12:30
02 Remy 12:45
03 Jerome 13:20
04 Remy 13:45
et avec un SGBD multivalué:
ID NOM CONNEXIONS
01 Jerome 12:30;13:20
02 Remy 12:45;13:45
Ca fait un peu gagne-petit, surtout vu les tailles des disques
actuels, et on peut arriver au même résultat en créant des tables
liées dans un SGBDR, d'où le fait que ce genre de bases soit en perte
de vitesse.
c'est gagne petit sur un niveau mais sur 4 niveaux c'est deja beaucoup plus
interessant imagine que chaque niveau a 10 valeurs 4 niveaux te donne 10000
comme rapport entre le relationnel et le mv la norme mv est defini sur 128
niveaux
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.
Si je cherche 14:00, ça me renvoit id 01 Jerome et id 02 Remy.
L'avantage dans ce cas est que je ne dois pas "tronconner" moi-même la
chaîne de caractère "CONNEXIONS", le système le faisant à ma place...
l'interro en pick est :
LISTER fichier AVEC CONNEXION = "14:00" NOM
resultat :
JEROME
REMY
Et j'obtiens le même resultat en demandant les noms correspondants à la
connexion 14:00, qui se traduit en SQL (dixit Access) par
SELECT Table1.Nom
FROM Table1 RIGHT JOIN Table2 ON Table1.Id = Table2.Id
WHERE ((Table2.Connexions)=#14:00#);
et comment je fais si je veux toutes les connexions de Jerome
il faut que je cree un autre dico ?
pour ca l'interro serait
LISTER fichier AVEC NOM = "Jerome" CONNEXION
resultat:
Jerome 12:30
13:20
14:00
Même topo: j'affiche les heures correspondantes au critère "Jérôme"
porté sur le nom. La traduction SQL est
SELECT Table2.Connexions
FROM Table1 RIGHT JOIN Table2 ON Table1.Id = Table2.Id
WHERE ((Table1.Nom)="Jerome");
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... ;-)
Par exemple, pour un log de connexion et un SGBD traditionnel, on aurait ID NOM CONNEXION 01 Jerome 12:30 02 Remy 12:45 03 Jerome 13:20 04 Remy 13:45
et avec un SGBD multivalué:
ID NOM CONNEXIONS 01 Jerome 12:30;13:20 02 Remy 12:45;13:45
Ca fait un peu gagne-petit, surtout vu les tailles des disques actuels, et on peut arriver au même résultat en créant des tables liées dans un SGBDR, d'où le fait que ce genre de bases soit en perte de vitesse.
c'est gagne petit sur un niveau mais sur 4 niveaux c'est deja beaucoup plus interessant imagine que chaque niveau a 10 valeurs 4 niveaux te donne 10000 comme rapport entre le relationnel et le mv la norme mv est defini sur 128 niveaux
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.
Si je cherche 14:00, ça me renvoit id 01 Jerome et id 02 Remy. L'avantage dans ce cas est que je ne dois pas "tronconner" moi-même la chaîne de caractère "CONNEXIONS", le système le faisant à ma place...
l'interro en pick est :
LISTER fichier AVEC CONNEXION = "14:00" NOM
resultat :
JEROME REMY
Et j'obtiens le même resultat en demandant les noms correspondants à la connexion 14:00, qui se traduit en SQL (dixit Access) par
SELECT Table1.Nom FROM Table1 RIGHT JOIN Table2 ON Table1.Id = Table2.Id WHERE ((Table2.Connexions)=#14:00#);
et comment je fais si je veux toutes les connexions de Jerome il faut que je cree un autre dico ?
pour ca l'interro serait
LISTER fichier AVEC NOM = "Jerome" CONNEXION
resultat:
Jerome 12:30 13:20 14:00
Même topo: j'affiche les heures correspondantes au critère "Jérôme" porté sur le nom. La traduction SQL est
SELECT Table2.Connexions FROM Table1 RIGHT JOIN Table2 ON Table1.Id = Table2.Id WHERE ((Table1.Nom)="Jerome");
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... ;-)
Philippe Lebon
Miod Vallat wrote:
Moi, j'ai été agent secret.
Et moi cosmonaute.
Avant ou apres ta carriere de J2EE lead architect ?
Juste avant que tu ne te transforme en nain de jardin.
-- En quittant le clan, le fils de Craô allait pour la première fois laisser un mystère derrière lui ... celui de cette lance qu'il n'éclaircirait sans doute jamais .. Car comment imaginer, en ces temps sauvages que certaines hordes façonnaient déjà une nouvelle matière .. Une matière dure et froide qu'on nommerait *fer*.
Miod Vallat wrote:
Moi, j'ai été agent secret.
Et moi cosmonaute.
Avant ou apres ta carriere de J2EE lead architect ?
Juste avant que tu ne te transforme en nain de jardin.
--
En quittant le clan, le fils de Craô allait pour la première fois laisser
un mystère derrière lui ... celui de cette lance qu'il n'éclaircirait sans
doute jamais .. Car comment imaginer, en ces temps sauvages que certaines
hordes façonnaient déjà une nouvelle matière .. Une matière dure et froide
qu'on nommerait *fer*.
Avant ou apres ta carriere de J2EE lead architect ?
Juste avant que tu ne te transforme en nain de jardin.
-- En quittant le clan, le fils de Craô allait pour la première fois laisser un mystère derrière lui ... celui de cette lance qu'il n'éclaircirait sans doute jamais .. Car comment imaginer, en ces temps sauvages que certaines hordes façonnaient déjà une nouvelle matière .. Une matière dure et froide qu'on nommerait *fer*.
