oui, ok, syndrome d'informaticien, mais c'est pas optimisé là!
Tu dis qu''il suffit de leur dire (sous entendu un nombre raisonnable de fois) pour qu'ils fassent attention, et tu proposes de le dire à tout le monde à chaque fois. En terme d'algo, c'est pas terrible :)
pour repartir de ton idée, ça pourrait être pas mal d'afficher ce message d'information pour les 5 ou 10 premiers commentaires/journaux
le post ci dessus est à -1, et je ne peux pas le "pertinenter" plusieurs fois, mais il mérite qu'on jette un oeil dessus.
Si CVS ne t'es pas imposé par une contrainte extérieur, autant se tourner vers Subversion (qui est le successeur naturel de CVS).
heu ... là je sais pas trop.
Cest vrai que j'ai pas de chiffres pour étayer ça, mais j'ai quand même l'impression qu'entre deux jointures et un IN et un NOT IN, il vaut mieux choisir les jointures.
sinon, les temps de réponse seront meilleurs si on a des indexs sur les champs bl et fac de facture_element.
attention! une vue est définie par un select, et ce select est effectué à chaque fois qu'on fait appel à la vue, en tout cas sous Oracle (et probablement pour les autres SGBDs). Du coup, la création de vue ne permet pas d'améliorer les performances.
je suis d'accord avec toi. C'est normal que tu ne veuilles pas créer une table pour remplacer une colonne, mais là, les associations entre tes entités (que tu refuses de modéliser mais qui existent quand même) ne sont pas de cardinalité 0-1 ou 1-1. Du coup, la table NE peut PAS être équivalente à une colonne.
j'ai discuté de ça avec un collègue. Il en sort que si tu veux pouvoir définir dynamiquement des relations entre différents type d'infos, ce que tu cherches à faire en fait, c'est un sgbd, et t'as de la chance, y'en a pleins ;)
je re répond parce que j'avais lu ta réponse un peu vite ...
non, il n'y a pas qu'une seule entité dans ton exemple
une date d'envoi par mail n'est pas lié à une photo.
y aurais plutot (par exemple) une entité photo d'un coté, une entité destinataire et une association entre les deux, l'association mail avec un attribut date pour l'association.
mouais, je comprend ce que tu veux faire ...
je ne sais pas s'il existe des équivalents.
En tout cas, si tu veux te lancer dans un truc aussi complexe, raison de plus pour modéliser proprement avec un schéma conceptuel avant de foncer dans le schéma relationnel ;)
as tu fais un schéma entité association?
comme ça, je dirais non, parce que sinon, tu te poserais pas autant de questions au moment de la définition des relations.
commence par avoir un bon schéma E/A, c'est à dire qui décrit exactement les entités (sans attribut artificiel comme les id) et les associations.
Ensuite, les relations découlent naturellement de ce schéma par des règles simples et sans ambiguité.
Vérifie que le résultat obtenu est bien normalisé, sinon, c'est que tu as une erreur de conception quelque part.
Parfois, à partir d'une relation pas normale, tu te rends compte que ton schéma E/A dont t'étais content est faux ...
pour répondre à ta question donc, oui j'ai une piste: un schéma E/A ;)
désolé, je connais pas bien mysql, donc c'est peut-être une question bête, mais si un insert vient se faufiler entre ton premier insert et ton select ?
à la place de
-------------------------------------------------------
functions.o : functions.c functions.h
--> gcc -Wall -c functions.c -o functions.o
parser.o : parser.c parser.h
--> gcc -Wall -c parser.c -o parser.o
-------------------------------------------------------
on peut aussi définir des règles pour make comme par exemple la règle suivante qui définit comment obtenir un .o à partir d'un .c
-------------------------------------------------------
.c.o:
--> gcc $(CFLAGS) -c $*.c
-------------------------------------------------------
$* est une variable automatique (point 10.5.3 de la doc de make http://www.gnu.org/software/make/manual/html_mono/make.html#SEC111(...) ). Le manuel de make, c'est du bonheur tellement y'a de trucs dedans :)
gaffe à pas oublier les tabulations (-->) en début de ligne
Je suis linuxien mais je ne suis pas pour le malheur des gens.
Je trouve ça vraiment triste pour eux, ce sont des hommes comme vous, qui passent leur journées à travailler dur, et ce travail n'est malheureusement pas récompensé.
ici, on parle de gens qui cherchent à se remplir les poches sur le dos des investisseurs, des utilisateurs, et des contributeurs de Linux (et même de leurs propres employés dont ils ont soigneusement détruit le travail). Alors, non, on est pas pour le malheur des gens, mais on peut quand même être content quand des enc... se font niquer.
le reste de ton poste est trop trollifique pour moi ou trop second degré. au choix.
Je sais pas vous, mais personnellement, quelque soit l'intention, je considère les chainmail comme quelque chose à bannir.
je suis à moitié d'accord. Le problème des chaines de mails, c'est qu'elles ne sont pas bornées dans le temps, du coup, des vieilles chaines, à l'origine "légitimes" (pas les chaines pour gagner un téléphone portable ou de l'argent de microsofft) continuent à trainer pour rien.
Par contre, en rajoutant un truc du genre: Avant de faire suivre ce mail, merci de vérifier la pertinence de cette chaine de mail en consultant "www.page-avec-le-statut-de-la-chaine-de-mail.org"
c'est mieux tout de suite. ca protège pas des boulets qui font suivre tout et n'importe quoi, mais je pense que ça pourrait marcher.
"L'OEB (...) est entièrement autonome sur le plan financier et tire ses ressources des taxes de procédure et des taxes de maintien en vigueur des demandes et des brevets."
en clair, plus il y a de brevets, plus ils gagnent d'argent. Du coup, soit ils examinent sérieusement tous les brevets (ce qui coute de l'argent parce que ça prend du temps), ils en rejettent beaucoup et ils manquent de sous, soit ils acceptent tous les brevets et ils ont plein de tunes...
pareil, je voulais demander: LEN: l'email n'est plus considéré comme de la correspondance privée. Alors que l'email est le courrier demain, que pensez vous de cette atteinte à la vie privée ?
meme réponse. Ils filtrent ou c'est l'infrastructure technique qui tient pas la route ?
[^] # Re: usa
Posté par gaaaaaAab . En réponse au message le site de bush aurait il un promblème. Évalué à 1.
et là http://politics.slashdot.org/article.pl?sid=04/10/27/1427228(...)
# optimisation
Posté par gaaaaaAab . En réponse au message Halte au langage SMS sur linuxfr!!!. Évalué à 1.
Tu dis qu''il suffit de leur dire (sous entendu un nombre raisonnable de fois) pour qu'ils fassent attention, et tu proposes de le dire à tout le monde à chaque fois. En terme d'algo, c'est pas terrible :)
pour repartir de ton idée, ça pourrait être pas mal d'afficher ce message d'information pour les 5 ou 10 premiers commentaires/journaux
gab
[^] # Re: glop
Posté par gaaaaaAab . En réponse au message sudo, sudoers et broken pipe !!!!. Évalué à 1.
+, c'est pour le netgroupe apache
le man de netgroup en sait plus que moi sur le sujet. Je te redirige donc vers lui plutot que de le paraphraser
# typo
Posté par gaaaaaAab . En réponse au message Communication interne et externe des programmes. Évalué à 3.
[^] # Re: Subversion ?
Posté par gaaaaaAab . En réponse au message CVS, notions confuses. Évalué à 1.
Si CVS ne t'es pas imposé par une contrainte extérieur, autant se tourner vers Subversion (qui est le successeur naturel de CVS).
[^] # Re: autojointure ?
Posté par gaaaaaAab . En réponse au message Optimisation d'une requête SQL ou choix d'un bon SGBD. Évalué à 2.
[^] # Re: autojointure ?
Posté par gaaaaaAab . En réponse au message Optimisation d'une requête SQL ou choix d'un bon SGBD. Évalué à 2.
Cest vrai que j'ai pas de chiffres pour étayer ça, mais j'ai quand même l'impression qu'entre deux jointures et un IN et un NOT IN, il vaut mieux choisir les jointures.
sinon, les temps de réponse seront meilleurs si on a des indexs sur les champs bl et fac de facture_element.
[^] # Re: Une vue
Posté par gaaaaaAab . En réponse au message Optimisation d'une requête SQL ou choix d'un bon SGBD. Évalué à 1.
# autojointure ?
Posté par gaaaaaAab . En réponse au message Optimisation d'une requête SQL ou choix d'un bon SGBD. Évalué à 2.
select (...)
from facture_element f, facture_element f1
(...)
where
(...)
and f.fac > 10000000
and f.bl = f1.bl
and f1.fac < 3000000
[^] # Re: question bête
Posté par gaaaaaAab . En réponse au message Base de données et nombre de colonne variable ?. Évalué à 1.
j'ai discuté de ça avec un collègue. Il en sort que si tu veux pouvoir définir dynamiquement des relations entre différents type d'infos, ce que tu cherches à faire en fait, c'est un sgbd, et t'as de la chance, y'en a pleins ;)
[^] # Re: question bête
Posté par gaaaaaAab . En réponse au message Base de données et nombre de colonne variable ?. Évalué à 1.
non, il n'y a pas qu'une seule entité dans ton exemple
une date d'envoi par mail n'est pas lié à une photo.
y aurais plutot (par exemple) une entité photo d'un coté, une entité destinataire et une association entre les deux, l'association mail avec un attribut date pour l'association.
[^] # Re: question bête
Posté par gaaaaaAab . En réponse au message Base de données et nombre de colonne variable ?. Évalué à 1.
je ne sais pas s'il existe des équivalents.
En tout cas, si tu veux te lancer dans un truc aussi complexe, raison de plus pour modéliser proprement avec un schéma conceptuel avant de foncer dans le schéma relationnel ;)
# question bête
Posté par gaaaaaAab . En réponse au message Base de données et nombre de colonne variable ?. Évalué à 2.
comme ça, je dirais non, parce que sinon, tu te poserais pas autant de questions au moment de la définition des relations.
commence par avoir un bon schéma E/A, c'est à dire qui décrit exactement les entités (sans attribut artificiel comme les id) et les associations.
Ensuite, les relations découlent naturellement de ce schéma par des règles simples et sans ambiguité.
Vérifie que le résultat obtenu est bien normalisé, sinon, c'est que tu as une erreur de conception quelque part.
Parfois, à partir d'une relation pas normale, tu te rends compte que ton schéma E/A dont t'étais content est faux ...
pour répondre à ta question donc, oui j'ai une piste: un schéma E/A ;)
[^] # Re: Quel SGBD ?
Posté par gaaaaaAab . En réponse au message [SQL]Changer le nom d'un champ dans une table. Évalué à 1.
ALTER TABLE table_name RENAME COLUMN old_name TO new_name
[^] # Re: ca sera mieux...
Posté par gaaaaaAab . En réponse au sondage Quand on n'aura plus de pétrole on aura. Évalué à 1.
http://www.ulb.ac.be/sciences/intra/inforsc_archives/nrj/carati.htm(...)
paragraphe: La fusion : les avantages du nucléaire sans ses inconvénients
[^] # Re: Pas possible
Posté par gaaaaaAab . En réponse au message Mysql : insert multi-tables. Évalué à 2.
alors en fait je me répond tout seul (si jamais ça interesse quelqu'un
d'autre) parce que j'ai trouvé dans la doc :
http://dev.mysql.com/doc/mysql/en/InnoDB_locking_reads.html(...)
SELECT LAST_INSERT_ID();
The SELECT statement merely retrieves the identifier information (specific to the current connection). It does not access any table.
je mets en gras
# expect
Posté par gaaaaaAab . En réponse au message Script Batch ou sh pour envoyer un autre script sur une machine distante et l'executer.. Évalué à 2.
google donne par exemple
http://www.cpqlinux.com/submit.html#FTPEXPECT(...)
[^] # Re: Makefile
Posté par gaaaaaAab . En réponse au message Indent & makefiles. Évalué à 1.
-------------------------------------------------------
functions.o : functions.c functions.h
--> gcc -Wall -c functions.c -o functions.o
parser.o : parser.c parser.h
--> gcc -Wall -c parser.c -o parser.o
-------------------------------------------------------
on peut aussi définir des règles pour make comme par exemple la règle suivante qui définit comment obtenir un .o à partir d'un .c
-------------------------------------------------------
.c.o:
--> gcc $(CFLAGS) -c $*.c
-------------------------------------------------------
$* est une variable automatique (point 10.5.3 de la doc de make http://www.gnu.org/software/make/manual/html_mono/make.html#SEC111(...) ). Le manuel de make, c'est du bonheur tellement y'a de trucs dedans :)
gaffe à pas oublier les tabulations (-->) en début de ligne
[^] # Re: petite traduction
Posté par gaaaaaAab . En réponse au message Tar erreur. Évalué à 1.
[^] # Re: Protection de copie : Politique des Major préférencielle en Europe e
Posté par gaaaaaAab . En réponse au journal Protection de copie : Politique des Major préférencielle en Europe et pas ailleurs ?. Évalué à 1.
[^] # Re: méchant !
Posté par gaaaaaAab . En réponse au journal Revenus (licences) de SCO : -99% !. Évalué à 1.
Je trouve ça vraiment triste pour eux, ce sont des hommes comme vous, qui passent leur journées à travailler dur, et ce travail n'est malheureusement pas récompensé.
ici, on parle de gens qui cherchent à se remplir les poches sur le dos des investisseurs, des utilisateurs, et des contributeurs de Linux (et même de leurs propres employés dont ils ont soigneusement détruit le travail). Alors, non, on est pas pour le malheur des gens, mais on peut quand même être content quand des enc... se font niquer.
le reste de ton poste est trop trollifique pour moi ou trop second degré. au choix.
[^] # Re: Relecture !
Posté par gaaaaaAab . En réponse au journal Mail d'information. Évalué à 3.
je suis à moitié d'accord. Le problème des chaines de mails, c'est qu'elles ne sont pas bornées dans le temps, du coup, des vieilles chaines, à l'origine "légitimes" (pas les chaines pour gagner un téléphone portable ou de l'argent de microsofft) continuent à trainer pour rien.
Par contre, en rajoutant un truc du genre:
Avant de faire suivre ce mail, merci de vérifier la pertinence de cette chaine de mail en consultant "www.page-avec-le-statut-de-la-chaine-de-mail.org"
c'est mieux tout de suite. ca protège pas des boulets qui font suivre tout et n'importe quoi, mais je pense que ça pourrait marcher.
# simplicité des brevets
Posté par gaaaaaAab . En réponse au journal Question sur les brevets.. Évalué à 3.
"L'OEB (...) est entièrement autonome sur le plan financier et tire ses ressources des taxes de procédure et des taxes de maintien en vigueur des demandes et des brevets."
en clair, plus il y a de brevets, plus ils gagnent d'argent. Du coup, soit ils examinent sérieusement tous les brevets (ce qui coute de l'argent parce que ça prend du temps), ils en rejettent beaucoup et ils manquent de sous, soit ils acceptent tous les brevets et ils ont plein de tunes...
[^] # Re: Problème
Posté par gaaaaaAab . En réponse au journal Chat avec Raffarin. Évalué à 2.
j'ai été déconnecté du chat quelques dizaines de seconde. Peux tu me confirmer qu'il n'a pas aborder les sujets qui nous intéresse pour l'instant ?
[^] # Re: Problème
Posté par gaaaaaAab . En réponse au journal Chat avec Raffarin. Évalué à 2.
LEN: l'email n'est plus considéré comme de la correspondance privée. Alors que l'email est le courrier demain, que pensez vous de cette atteinte à la vie privée ?
meme réponse. Ils filtrent ou c'est l'infrastructure technique qui tient pas la route ?