Vous n'êtes pas identifié(e).
Pages : 1
La jointure croisée était la bonne idée. Merci !
Par contre j'ai modifié la clause WHERE afin qu'elle reponde mieux à mon souhait !
edlm a bien compris ce que je voulais faire.
je vais essayer la requete voir si ca repond à mon besoin et faire un retour après
merci
CAS1:
SELECT depart,arrivée FROM matable where id=1
depart - arrivée
0 3
5 50
10 30
--------------------
CAS2:
SELECT depart,arrivée FROM matable where id=2
depart - arrivée
5 50
10 30
20 40
cas1 et cas sont deux résultats de la même requete.
je ne veux pas faire de jointure entre des deux requetes mais exploiter le resultat de chacune.
Est-ce compréhensible ce que je raconte ?
Euh je pense que vous avez pas bien compris ou que j'ai mal formulé ma question ...
En fait CAS1 et le résultat d'un premier SELECT
et CAS2 est le résultat d'un deuxième SELECT
Je cherche pour chaque SELECT si j'ai un intersection ou pas.
Dans le premier SELECT je n'ai pas d'intersection car la ligne depart=0 et arrivée=3 n'a pas d'intersection avec les autres lignes.
Dansle deuxième SELECT j'ai une intersection entre les trois lignes sur la partie 20-30
Est-ce plus clair ?
Bonjour,
J'ai mon select qui me renvoie ça :
--------------------
CAS1:
depart - arrivée
0 3
5 50
10 30
--------------------
CAS2:
depart - arrivée
5 50
10 30
20 40
--------------------
Je voudrais savoir si on peut trouver via SQL (avec les fonction window ???) que ces SELECT ont une "partie" commune (cf CAS2 : "partie" 20-30) ou pas (cf CAS1)
Merci d'avance si vous pouvez m'aider
Bonjour.
Je ne crois pas qu'il soit possible de le faire via un script, mais uniquement par l'interfaced'administration disponible sur http://sql.free.fr/phpPgAdmin/
Depuis quelque temps je ne peux plus faire de dump au format SQL via cette interface ... Je ne sais pas si c'est un bug chez free ...
Personne n'a une petite idée pour moi 
Bonjour,
Je souhaiterais savoir comment sauvegarder ma base de données PostgreSQL hébergé via les pages perso de free via un script et la commande pg_dump (php ?)
Merci d'avance
Un afficheur réglé sur latin1 ne pourrait pas afficher [œ] puisque ce caractère n'existe pas dans le jeu de caractères latin1.
Voir http://fr.wikipedia.org/wiki/ISO_8859-1
Je suis d'accord avec vous sur la théorie, d'où l'incrédulité de mon premier mesage ! Mais en pratique j'ai bien [œ] ....
le problème c'est que l'"afficheur est réglé" sur latin1 et pas latin9
lc_collate=C
lc_ctype=C
Ma base de données est en LATIN1 (ISO 8859-1) or je trouve dans des tables des caractères comme "œ" de LATIN9 (ISO 8859-15).
Je précise que le caractère est telque et pas sous son code iso &#xxx; ou sous un autre forme
Comment cela est-ce possible ?
OK merci de votre réponse.
Je vais voir si je peux diminuer le nombre de requêtes.
Voici les réponses à vos questions :
Donc la requête 4 s’exécute 5241 fois pour une durée totale de 9,89s soit une moyenne de 0,0019s
En détail 5000 requêtes font moins de 0,0025s et quelques requêtes ont des durée élevées (... 0,0113s, 0,0117s, 0,0127s, 0,0138s)
Donc la requête 5 s’exécute 5241 fois pour une durée totale de 4,99s soit une moyenne de 0,0009s
Requête1 "ultra simple"
Boucle sur les 377 résultats
Requête 2 "ultra simple"
Boucle sur les n résultats (une dizaine à chaque fois)
Requête4 (décrite plus haut)
Requête5 (structure "idem" requête 4)
Fin Boucle
Fin Boucle
La requête4 décrite dans mon premier message s'éxécute 5000 fois en fait (la requête 5 aussi)
Ce bout de script prend 17 secondes.
Bonjour,
J'ai un script php avec plusieurs requêtes qui est trop long à l'exécution. Je me demande si je n'ai pas de l'optimisation à faire dans une requête qui est éxécuté plus de 3000 fois
TABLE TABX : plusieurs colonnes avec clé primaire sur COLX1 et index sur COLX2
TABLE TABY : plusieurs colonnes avec clé primaire sur COLY1 et COLY2 et clé étrangère sur COLY1 qui référence TABX.COLX1
SELECT count(*)
FROM TABY, TABX
WHERE TABY.COLY1=TABX.COLX1 AND TABX.COLX2 <='$date' AND TABY.COLY2='".$id."'"
Quand pensez-vous ?
Merci d'avance
Bonjour,
J'ai testé votre requête sur PostgreSQL 8.3.1 et j'ai également le message "ERROR: function convert(character varying, unknown, unknown) does not exist". Pas d'explication ...
PS: Je rajoute une question. En terme de performance faut-il mieux faire un ILIKE ou un LOWER (ou UPPER) pour faire de la recherche en case insensitive ?
Dans mon mail précédent, les colonnes ColC1, ColC2 ... ColC5 sont héritées de la Table A donc sont respectivement égales à ColA1, ColA2 ... ColA5.
La clé primaire est sur ColC1 donc sur ColA1.
Ce qui ne marche pas c'est la clé étrangère sur ColB2 référençant ColA1 car celle ci recherche les valeurs dans ColA1 (clé primaire de la table mère) mais pas dans ColC1 (clé primaire de la table fille)
En fait le terme "bloque" est peut être un peu fort...
Je souhaitais faire une évolution sur une de mes tables pour optimisation et amélioration de mon MCD mais qui n'est à priori pas possible.
Ma situation Actuelle :
Table A : ColA1 ColA2 ColA3 … ColA11 (->11 colonnes)
clé primaire sur ColA1
Table B : ColB1 ColB2
clé étrangère sur ColB2 référençant ColA1
Ma situation désirée :
Table A : ColA1 ColA2 ColA3 ColA4 ColA5 (->5 colonnes)
clé primaire sur ColA1
Table C : qui hérite de la table A: ColC1 ColC2 ColC3 ColC11 (->5 + 6 colonnes)
clé primaire sur ColC1
Table B : ColB1 ColB2
clé étrangère sur ColB2 référençant ColA1
Bonjour à tous !
Merci à l'ensemble des personnes qui font vivre ce site.
Je suis un "petit" webmaster (voir mon site dans ma signature) qui a décidé de laisser tomber MySQL pour PostgreSQL.
J'ai donc migré ma base de données dernièrement. Le plus gros du travail était la correction de mes requêtes SQL. Sinon tout c'est bien passé et je suis bien satisfait de PostgreSQL.
Toutefois, je suis "déçu" par l'héritage qui est souvent cité comme un avantage dans PostgreSQL. Pour l'instant un point me bloque totalement :
cf. http://docs.postgresql.fr/8.4/ddl-inherit.html
"si une autre table indique REFERENCES villes(nom), cela l'autorise à contenir les noms des villes mais pas les noms des capitales. Il n'existe pas de contournement efficace de ce cas."
Voilà, c'était juste pour faire un petit retour sur ma petite expérience de migration et d'utilisation de PostgreSQL.
Pages : 1
