Vous n'êtes pas identifié(e).

Pages : 1 2 3 … 8

#1 Re : Général » Format date stocké en MM/DD » 02/04/2019 21:56:36

damalaan
gleu a écrit :

C'est très difficile de vous répondre vu qu'on ne connaît pratiquement rien du contexte. Avec le peu d'infos qu'on a, je dirais de stocker quand même les dates. Ça ne coute pas grand chose et ça permet d'utiliser un vrai type date et les fonctions associées. Voire un daterange, qui serait certainement plus pratique pour vous.


oh que je suis d'accord !!
par expérience, si vous avez des dates à gérer utilisez le bon type (date)
j'utilise au quotidien une (vieille) base (oracle) avec des dates séparées en 3 champs (année, mois jour)
je vous laisse imaginer quand vous rajoutez une journée au 31/12/2018........et bien on est le 32/12/2018!
et si vous retranchez 5 jours au 03/02/2018......c'est la misère
la solution est le typage à la volée dans les requêtes mais les perf s'effondrent, et oracle en plus gère assez mal ça dans le prédicat
alors qu'avec un type date et une base postgres tout cela se fait naturellement sans maux de tête !

#2 Re : Général » chercher des données chez Oracle » 16/11/2018 09:21:12

damalaan

Le plus pénible à installer dans l'histoire c'est l'instant client Oracle !!
Mais une fois que c'est fait, ça fonctionne bien.
Bon courage !

#3 Re : Général » chercher des données chez Oracle » 15/11/2018 22:40:59

damalaan

Bonjour,

J'avais fait un post sur ce sujet il y a quelques temps : https://forums.postgresql.fr/viewtopic.php?id=4122
ainsi qu'un petit "tuto" récapitulatif de l'installation : https://www.developpez.net/forums/blogs … posgresql/

si cela peut vous aider.....oracle est tellement galère à installer

#4 Re : Général » [RESOLU]requete sur un champs jsonb » 19/06/2018 09:33:12

damalaan
duple a écrit :

Par curiosité, quelle est le réel intérêt de stoquer les données ainsi dans un champs json, la modèlisation ne pourrait être autrement ?

sais pas !!! dans ce cas je ne suis qu'utilisateur !!

#5 Re : Général » [RESOLU]requete sur un champs jsonb » 18/06/2018 14:45:48

damalaan

Yes merci
c'est un peu sportif cette histoire, voilà le code final pour extraire tous les éléments

select client , json_array_elements_text(json_array_elements(champjson::json)->'d')::int as pb FROM matable

par contre il  faut "retyper" le jsonb en json sinon ça ne fonctionne pas

#6 Général » [RESOLU]requete sur un champs jsonb » 18/06/2018 12:22:48

damalaan
Réponses : 4

Bonjour,

je dois faire une requête sur une table dont un des champs est en jsonb avec un stockage du style :

client, champjson
1234, [{"a": "", "b": "", "c": "", "d": [19, 38, 34, 13], "e": ""}]
4321,[{"a": "", "b": "", "c": "", "d": [36], "e": ""}]

je souhaite que le résultat de ma requête soit ainsi :

1234,19
1234,38
1234,34
1234,13
4321,36

j'ai donc tenté une requête comme ceci : 

 select client, champjson->'d' from matable

et j'obtien

1234,NULL
4321,NULL

merci de votre aide

#7 Re : Général » [RESOLU] Mise en place de Foreign Data Wrappers Oracle » 02/03/2018 14:50:40

damalaan

Il semblerait que ce soit natif :  https://raw.githubusercontent.com/laure … oracle_fdw

Joins between foreign tables
----------------------------

From PostgreSQL 9.6 on, oracle_fdw can push down joins to the Oracle server,
that is, a join between two foreign tables will lead to a single Oracle query
that performs the join on the Oracle side.

There are some restrictions when this can happen:

- Both tables must be defined on the same foreign server.
- The join must be an inner join.
- Joins between three or more tables won't be pushed down.
- The join must be in a SELECT statement.
- oracle_fdw must be able to push down all join conditions and WHERE clauses.
- Cross joins without join conditions are not pushed down.
- If a join is pushed down, ORDER BY clauses will not be pushed down.

It is important that table statistics for both foreign tables have been
collected with ANALYZE for PostgreSQL to determine the best join strategy.

#8 Re : Général » [RESOLU] Mise en place de Foreign Data Wrappers Oracle » 02/03/2018 12:09:37

damalaan

Bonjour

Effectivement, je viens de me le faire, c'est top !!
je n'avais pas envisager ça au moment où j'avais commencé ce post (1 an déjà ....), je n'avais besoin que de quelques tables oracle.
ce qui me manque toujours c'est les clefs et les index, sur des select simple (1 table ça va à peu près), mais dès qu'on passe pas des jointures, les durées d'exécution sont catastrophiques.

Comme vous êtes sur une version plus récente, y a t il eu des améliorations sur ce point ?

#9 Re : Général » Calculer une médiane pondérée » 30/01/2018 13:22:21

damalaan

si je pondère ma moyenne finale j'obtiens la même chose qu'en R : 10.873 (c'est moche et tordu.....)

with b as (
select sum(pond) as total from test
),
c as (
select prix, round(pond / total,2) as pond2 from test, b),
d as (
select prix, pond2,
sum(pond2) over (partition by 1 order by prix range between unbounded preceding and current row) as cumul_asc
from c),
e as (
select prix, pond2,
sum(pond2) over (partition by 1 order by  prix desc range between unbounded preceding and current row) as cumul_desc
from c),
f as (
select max(d.prix) as resultat from d where cumul_asc <=.5 
union 
select min(e.prix)  from e where cumul_desc <=.5)
select sum(resultat*pond)/sum(pond) from f,test where resultat=prix

#10 Re : Général » Calculer une médiane pondérée » 30/01/2018 10:45:32

damalaan

d'après ce que j'ai pu comprendre et vérifier par le calcul, R recherche les "limites" encadrantes et calcule la moyenne pondérée de ces limites :

prix	pondération
10.606	5.554
11	11.705

en calculant la moyenne pondérée on tombe sur 10.873
(10.606*5.554+11*11.705)/(5.554+11.705)

#11 Re : Général » Calculer une médiane pondérée » 30/01/2018 10:11:06

damalaan

j'étais parti sur ce genre de chose avec les fonctions de fenêtrage mais en découpant beaucoup (trop) les requêtes, en ramenant les pondération à 1...... et j'obtiens 10.80

je vous mets quand même ma requête

with b as (
select sum(pond) as total from test),
c as (
select prix, round(pond / total,2) as pond2 from test, b),
d as (
select prix, pond2,
sum(pond2) over (partition by 1 order by prix range between unbounded preceding and current row) as cumul_asc
from c),
e as (
select prix, pond2,
sum(pond2) over (partition by 1 order by  prix desc range between unbounded preceding and current row) as cumul_desc
from c),
f as (
select max(d.prix) as resultat from d where cumul_asc <=.5 
union 
select min(e.prix)  from e where cumul_desc <=.5)
select avg(resultat)  from f

avec la solution de dverite, on obtient 10.94

En R, avec la fonction weighted.median de la library spatstat, avec le jeu de données fourni j'obtiens 10.87

#12 Re : Général » Calculer une médiane pondérée » 29/01/2018 12:37:45

damalaan

je ne connaissais pas la médiane pondérée, merci donc à wikipedia : https://en.wikipedia.org/wiki/Weighted_median#Examples
ça n'a pas l'air simple comme ça....
Il semble que des logiciel de stats tel R propose ce genre de fonction (weight.median) (une extension existe pour postgres)
Je ne pense pas que l'on puisse simplement trouver la médiane pondérée sans passer par un certain nb d'étape intermédiaire ou un prog en pg/sql.

Néanmoins, rien n'étant impossible, qu'attendez-vous comme résultat final avec le jeu de données précédent ?

#13 Re : Général » Calculer une médiane pondérée » 25/01/2018 09:20:15

damalaan

Un exemple chiffré pourrait permettre de mieux y voir clair, mais vu la requête, je pense que vous retombez direct sur la valeur de votre variable, elle n'est donc pas pondérée.
Faites une mediane sur vos valeurs non pondérées pour voir.......
Bizarre également la fonction median........ce n'est pas implémenté tel que dans postgresql (il faut ça SELECT percentile_disc(0.5) WITHIN GROUP (ORDER BY champ) FROM TABLE pour avoir la mediane)

#14 Re : Optimisation » Gestion des intervalles de dates » 24/01/2018 17:43:40

damalaan

Je me réponds après quelques essais !!
J'avais comme l'intuition que LATERAL pourrait venir à mon secours....

SELECT a.ech, lat.lot, a.ana, a.ech_dh,lat.lot_dh FROM ech a, 
	LATERAL (SELECT * FROM lot b WHERE b.ana = a.ana AND a.ech_dh>=b.lot_dh ORDER BY lot_dh DESC LIMIT 1) lat

J'ai toujours du mal à appréhender la logique de LATERAL....si vous avez un bon tuto par là, je suis preneur !

#15 Optimisation » Gestion des intervalles de dates » 18/01/2018 15:32:20

damalaan
Réponses : 1

Bonjour,

Dans le cadre d'une gestion de stock et d'analyses, j'ai les 2 tables suivantes (simplifiées pour l'exemple):

CREATE TABLE public.lot (
	lot varchar NULL, --numero de lot
	ana varchar NULL, --analyse realise avec le lot
	lot_dh timestamp NULL --date d'activation du lot
)

INSERT INTO public.lot (lot,ana,lot_dh) VALUES 
('lot1','ST','2017-12-31 08:03:54.000')
,('lot2','C','2018-01-05 12:12:54.000')
,('lot3','FT','2018-01-10 12:03:54.000')
,('lot5','C','2018-01-15 15:15:54.000')
,('lot6','FT','2018-01-14 11:13:14.000')
,('lot4','ST','2018-01-02 18:03:54.000')


CREATE TABLE public.ech (
	ana varchar NULL, --analyse
	ech_dh timestamp NULL, --date/heure de realisation de l'analyse
	ech int4 NULL --numero echantillon
)
INSERT INTO public.ech (ana,ech_dh,ech) VALUES 
('ST','2017-12-31 08:02:54.000',1)
,('C','2018-01-05 12:12:59.000',2)
,('FT','2018-01-05 12:12:59.000',2)
,('ST','2018-01-15 17:12:59.000',3)
,('FT','2018-01-15 17:12:59.000',3)
,('C','2018-01-15 17:12:59.000',3)

Le but est de retrouver le lot utilisé pour l'échantillon pour telle ou telle analyse.
Par exemple, on sait donc que le lot4 servira à faire l'analyse ST, et qu'il est actif à partir du 02/01/2017 18:03:54
Donc, tant qu'un nouveau lot réalisant cette analyse n'est pas activé, les échantillons seront faits avec le lot 4.

Pour que l'utilisateur puisse obtenir une traçabilité je pensais donc à cette requête avec une reconstitution d'intervalle de date, et qui permet de retourner les échantillons avec les lots utilisés

WITH a AS(
	SELECT
		lot,
		ana,
		lot_dh AS date_val_deb,
		lead(
			lot_dh,
			1
		) OVER(PARTITION BY ana	ORDER BYlot_dh ASC) AS date_val_fin
	FROM
		lot
	ORDER BY
		ana,
		lot
),
b AS(
	SELECT
		lot,
		ana,
		CASE
			WHEN date_val_deb IS NULL THEN '(,' || date_val_fin || ')'
			WHEN date_val_fin IS NULL THEN '[' || date_val_deb || ',)'
			ELSE '[' || date_val_deb || ',' || date_val_fin || ')'
		END::tsrange AS plage_val_lot
	FROM
		a
) SELECT
	ech,
	lot,
	ech.ana,
	ech_dh,
	plage_val_lot
FROM
	ech
LEFT JOIN b ON
	ech.ana = b.ana
WHERE
	ech_dh < @ plage_val_lot = TRUE

ce qui me donne 

ech |lot  |ana |ech_dh              |plage_val_lot                                 |
----|-----|----|--------------------|----------------------------------------------|
2   |lot2 |C   |2018-01-05 12:12:59 |["2018-01-05 12:12:54","2018-01-15 15:15:54") |
3   |lot5 |C   |2018-01-15 17:12:59 |["2018-01-15 15:15:54",)                      |
3   |lot6 |FT  |2018-01-15 17:12:59 |["2018-01-14 11:13:14",)                      |
3   |lot4 |ST  |2018-01-15 17:12:59 |["2018-01-02 18:03:54",)                      |

Y aurait il plus simple ? plus efficace ?
Merci d'avance

#16 Re : Général » x en fonction <= a la date » 12/01/2018 16:31:51

damalaan

Vos 2 tables semblant identiques, ne faudrait-il pas revoir le modèle :
U
Date
Type (budget ou depense)
Montant
?

Ensuite avec une fonction de fenêtrage, on doit pouvoir travailler facilement sur chaque partition (U)

#17 Général » calcul d'une moyenne cumulée » 14/12/2017 09:52:41

damalaan
Réponses : 0

Bonjour,

Plutôt qu'une question, ce post est un partage d'expérience, la doc étant sans exemple sur ce sujet
En faisant des recherches sur les fonctions de fenêtrage, je suis tombé sur cet article
http://sqlpro.developpez.com/article/ol … dow/#LII-C

Pour un calcul de moyenne cumulée, c'est parfait : 

select sta_id, val_date,val_esp, val_valeur,
avg(val_valeur) over (partition by sta_id, val_esp order by val_date RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) as moy_cumulée 
from tbl_valeur_val
where val_date > '05/12/2017'

Ici je calcule pour chaque champ sta_id et val_esp la moyenne cumulée par date croissante

sta_id |val_date   |val_esp |val_valeur |moy_cumulée            |
-------|-----------|--------|-----------|-----------------------|
1      |2017-12-06 |1       |741.000    |741.0000000000000000   |
1      |2017-12-07 |1       |671.000    |706.0000000000000000   |
1      |2017-12-08 |1       |404.000    |605.3333333333333333   |
1      |2017-12-09 |1       |252.000    |517.0000000000000000   |
1      |2017-12-12 |1       |1.000      |413.8000000000000000   |
1      |2017-12-13 |1       |7.000      |346.0000000000000000   |
1      |2017-12-06 |2       |395.000    |395.0000000000000000   |
1      |2017-12-07 |2       |287.000    |341.0000000000000000   |
1      |2017-12-08 |2       |42.000     |241.3333333333333333   |
1      |2017-12-09 |2       |89.000     |203.2500000000000000   |
1      |2017-12-12 |2       |115.000    |185.6000000000000000   |
1      |2017-12-13 |2       |131.000    |176.5000000000000000   |
2      |2017-12-06 |1       |15.000     |15.0000000000000000    |
2      |2017-12-07 |1       |20.000     |17.5000000000000000    |
2      |2017-12-08 |1       |19.000     |18.0000000000000000    |
2      |2017-12-09 |1       |17.000     |17.7500000000000000    |
2      |2017-12-12 |1       |40.000     |22.2000000000000000    |
2      |2017-12-13 |1       |158.000    |44.8333333333333333    |
2      |2017-12-06 |2       |31.000     |31.0000000000000000    |
2      |2017-12-07 |2       |34.000     |32.5000000000000000    |
2      |2017-12-08 |2       |45.000     |36.6666666666666667    |
2      |2017-12-09 |2       |38.000     |37.0000000000000000    |
2      |2017-12-12 |2       |38.000     |37.2000000000000000    |
2      |2017-12-13 |2       |26.000     |35.3333333333333333    |
3      |2017-12-06 |1       |10.000     |10.0000000000000000    |
3      |2017-12-07 |1       |10.000     |10.0000000000000000    |
3      |2017-12-08 |1       |10.500     |10.1666666666666667    |
3      |2017-12-09 |1       |11.000     |10.3750000000000000    |
3      |2017-12-12 |1       |40.000     |16.3000000000000000    |
3      |2017-12-13 |1       |16.000     |16.2500000000000000    |
3      |2017-12-06 |2       |22.000     |22.0000000000000000    |
3      |2017-12-07 |2       |23.000     |22.5000000000000000    |
3      |2017-12-08 |2       |21.000     |22.0000000000000000    |
3      |2017-12-09 |2       |28.000     |23.5000000000000000    |
3      |2017-12-12 |2       |20.000     |22.8000000000000000    |
3      |2017-12-13 |2       |22.000     |22.6666666666666667    |
4      |2017-12-06 |1       |714.000    |714.0000000000000000   |
4      |2017-12-07 |1       |633.000    |673.5000000000000000   |
4      |2017-12-08 |1       |384.000    |577.0000000000000000   |
4      |2017-12-09 |1       |243.000    |493.5000000000000000   |
4      |2017-12-12 |1       |1.000      |395.0000000000000000   |
4      |2017-12-13 |1       |6.000      |330.1666666666666667   |
4      |2017-12-06 |2       |349.000    |349.0000000000000000   |
4      |2017-12-07 |2       |252.000    |300.5000000000000000   |
4      |2017-12-08 |2       |38.000     |213.0000000000000000   |
4      |2017-12-09 |2       |71.000     |177.5000000000000000   |
4      |2017-12-12 |2       |104.000    |162.8000000000000000   |

#18 Re : Général » [RESOLU] Fonction Médiane » 28/04/2017 08:46:57

damalaan

ok je m'incline !
c'est pas évident, faut le savoir !
merci de cette réponse rapide

#19 Général » [RESOLU] Fonction Médiane » 28/04/2017 08:17:17

damalaan
Réponses : 2

Bonjour

Je veux "déporter" des calculs effectués actuellement sous oracle dans postgresql avec des foreign tables.
Mais postgres ne possède pas de fonction médiane intégrée (quel dommage=>pour la 9.7 peut être :-) ). Le but serait de pouvoir utiliser cette fonction créée de toutes pièces comme dans oracle : select median(monchamp) from....
Auriez-vous qq idées sur cette médiane ?
merci

#20 pgAdmin4 » paramétrage de l'éditeur SQL » 27/04/2017 08:59:58

damalaan
Réponses : 1

Bonjour

J'utilise pgadmin4 (en v1.4 actuellement) de temps en temps pour voir son évolution (d'habitude j'utilise pgadmin3 en 1.22.2 pour postgres 9.6)
je ne trouve la possibilité de paramétrer la casse des mots clefs SQL (que je voudrais mettre en majuscules automatiquement).
J'ai remarqué aussi que les commentaires (-- ou /* */) ne sont pas matérialisés comme tels (en vert dans pgadmin3), y a t il également un paramétrage que j'ai loupé ?!

merci

#21 Re : Général » [RESOLU] Mise en place de Foreign Data Wrappers Oracle » 02/03/2017 09:17:46

damalaan

Comme promis, j'ai fait un petit tuto sur le blog de developpez.com https://www.developpez.net/forums/blogs … posgresql/

#22 Re : Général » [RESOLU] Mise en place de Foreign Data Wrappers Oracle » 22/02/2017 11:27:58

damalaan

ça y est, je peux faire un select !!

CREATE EXTENSION oracle_fdw;
CREATE SERVER oracle_labo  FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver 'LABO');
GRANT USAGE ON FOREIGN SERVER oracle_labo TO postgres;

CREATE USER MAPPING FOR postgres SERVER oracle_labo
          OPTIONS (user 'labo', password '****');

CREATE FOREIGN TABLE ora_table
   (........
)
   SERVER oracle_labo
   OPTIONS (table 'latable_oracle');

En fait j'ai enlevé le schema dans les options à la création de la table (la doc disant que c'est optionnel)

A voir maintenant à l'usage dans le temps.....
Quand j'aurai un petit moment je remettrai un message avec l'installation de a à z, ça peut servir....
Encore merci pour votre à tous !

#23 Re : Général » [RESOLU] Mise en place de Foreign Data Wrappers Oracle » 21/02/2017 16:07:22

damalaan

Je suis carrément novice en gestion des accès sad mais je sens que qu'il va falloir que j'apprenne.

Sous oracle, un user "labo" peut se connecter à cette table.
Comment dois-je procéder pour qu'un utilisateur connecté à pg puisse avoir accès à cette foreign table ?

#24 Re : Général » [RESOLU] Mise en place de Foreign Data Wrappers Oracle » 21/02/2017 15:52:20

damalaan

J'ai refait toute mon install sur une machine virtuelle, propre et neuve !
J'ajoue que je ne sais pas ce qui a changé (à part la version de pg 9.6 au lieu de 9.5 ainsi que la version du oracle_fdw), mais à force de tripatouiller j'ai du m........

Cette fois je pense qu'il s'agit d'un problème de droit car voici l'erreur quand je fais un select sur la foreign table

ERREUR:  Oracle table "LABO"."LA_TABLE" for foreign table "ora_latable" does not exist or does not allow read access
DETAIL:  ORA-00942: Table ou vue inexistante
HINT:  Oracle table names are case sensitive (normally all uppercase).

Je suis connecté avec l'utilisateur postgres.

Qu'en penser ?

#25 Re : Général » [RESOLU] Mise en place de Foreign Data Wrappers Oracle » 21/02/2017 09:34:46

damalaan

Je savais bien qu'avec Oracle ça serait pas simple:(

J'ai essayé les manips suivantes :
-installer Microsoft Visual C++ 2015 Redistributal” and Java Runtime Environment (version 7 or 8) (comme demandé dans le lien )
-l'instant client est déjà en place puisque j'utilise aussi une connexion odbc pour autre chose
-j'ai tout supprimé et tout recréé dans postgres  comment je l'ai décrit dans un post ci dessus.
-à la création de la table étrangère j'ai spécifié le schéma où elle se trouve dans oracle 

.....
SERVER oracle_labo
   OPTIONS (schema 'LABO', table 'toto');

Jusque là ça se passe bien

J'ai vérifier les variable d'environnement :
ORACLE_PATH : C:\oracle\instantclient_11_2
TNS_ADMIN : %ORACLE_PATH%
Path : beaucoup de chose dont C:\oracle\instantclient_11_2

et j'ai toujours la même erreur sad

Pages : 1 2 3 … 8

Pied de page des forums

Propulsé par FluxBB