Vous n'êtes pas identifié(e).
Bonjour,
Je me permet de vous adresse ma question bien que je re-découvre SQL (souvenir d'IUT). J'espère que vous pourrez accéder à ma demande ou me rediriger.
J'utilise une base Postgres. Je possède plusieurs tables qui enregistrent les activités utilisateurs d'un système. Pour chaque semaine, j'ai 1 table. Je souhaite rechercher des actions précises sur 1 mois. Donc je dois faire une recherche sur 4 tables. j'essaye d'obtenir le résultat en 1 seule fois.
Les tables sont :
trans_log_y2015_w29
trans_log_y2015_w30
trans_log_y2015_w31
trans_log_y2015_w32
Le nom des colonnes qui m'intéressent dans ces tables sont :
"timestamp"
client_ip
user_name
action_code
primary_device
secondary_device
Je souhaite filtrer sur la colonne action_code avec comme résultat la valeur 1007.
Pour 1 table, ma requête se présente ainsi :
SELECT
"timestamp", client_ip, user_name,
action_code, primary_device, secondary_device
FROM
trans_log_y2015_w32
WHERE
action_code = '1007';
;
*ça m'a pris 1 heure*
Dans un second temps, sans faire de filtre et sur 2 tables, j'ai réalisé cette requête :
SELECT
S1."timestamp", S1.client_ip, S1.user_name,
S1.action_code, S1.primary_device, S1.secondary_device,
S2."timestamp", S2.client_ip, S2.user_name,
S2.action_code, S2.primary_device, S2.secondary_device
FROM
trans_log_y2015_w32 AS S1,
trans_log_y2015_w33 AS S2
;
Je me suis rendu compte que les colonnes étaient mis "bout à bout". En cherchant tout l'après midi, j'ai trouvé le site : http://sql.sh/cours/ et j'ai compris qu'un NATURAL JOIN pouvait répondre à mon problème :
SELECT
S1."timestamp", S1.client_ip, S1.user_name,
S1.action_code, S1.primary_device, S1.secondary_device,
S2."timestamp", S2.client_ip, S2.user_name,
S2.action_code, S2.primary_device, S2.secondary_device
FROM
trans_log_y2015_w32 AS S1 NATURAL JOIN
trans_log_y2015_w33 AS S2
;
Mais le résultat de mes colonnes est vide et j'ai toujours une représentation "bout à bout".
Qu'en pensez vous ?
Merci,
Jérôme
PS : je peux ajouter des screen shot ?
Dernière modification par c0c0 (12/08/2015 16:27:09)
Hors ligne
Bonjour,
En ayant lu votre problème je me suis arrêté sur plusieurs points, mais surtout celle-ci :
"Pour chaque semaine, j'ai 1 table" (cf : trans_log_y2015_w29, trans_log_y2015_w30, trans_log_y2015_w31)
Cela me rappelle une entreprise d'une chaine de restaurants (dont je ne citerais pas le nom) qui faisait de même pour gérer son SI. Ma question est : le partitionnement n'était t-il pas envisageable plutôt que de se casser la tête à créer 52 tables par an ?
Un NATURAL JOIN n'est rien d'autre qu'une syntaxe sucrée pour une jointure interne, pas une solution miracle. D'après la lecture de votre message, je dirais que vous cherchez à réaliser un UNION entre vos différentes tables.
PS: Pourquoi utiliser un nom de colonne identique qu'un type ? C'est comme appeler une colonne "entier" parce que son contenu est un entier.
Hors ligne
Bonjour guk92,
Merci d'avoir pris le temps de me lire et me répondre.
Je travail pour une société qui intègre des solutions logiciels pour des clients. Je ne décide pas de la façon dont est conçu le logiciel ni la BDD et j'utilise rarement la BDD comme j'essaye de le faire. Parfois, mon client émet des demandes qui nécessitent de creuser un peu plus loin. Mais pourquoi ne pas demander au fournisseur ? Ou faire évoluer tout ça ? Faute de budget ! Comme bien souvent... Du coup j'essaye de me "dépatouiller".
Techniquement : a la base il existait 1 table par année. Les données enregistrées étaient très volumineuse. Le logiciel propose à l'utilisateur de consulter les "logs d'activités" qui sont contenus dans ces tables via une interface. A l'époque, lorsqu'il n'y avait qu'une table, cela fonctionnait mal. Le fournisseur a décidé de créer 1 table par semaine et c'est mieux.
Je ne connais pas le "partitionnement" n'hésitez pas à m'orienter vers cette information si besoin.
De même, je ne sais répondre à votre question :
"Pourquoi utiliser un nom de colonne plutôt qu'un type ?"
La colonne "primary_device" contient en réalité des ID (des nombres entiers). Le nom de la colonne me semble être "primary_device", ce n'est donc pas un type.
Vous proposez de faire plusieurs requêtes et d'utiliser UNION. Je suis allé voir ce que cela veut dire et je pense que c'est la solution à mon problème.
Je crains une lourdeur dans l’exécution de cette requête, mais c'est une autre histoire.
Je vous tiens informer,
Merci pour votre aide.
Hors ligne
Le partitionnement est une optimisation, n'hésite pas à consulter la documentation pour mieux saisir le principe.
J'ai dit UNION pour t'introduire à l'opérateur ensembliste, mais utilise plutôt UNION ALL pour ton besoin (ça sera moins lourd) 
Hors ligne
Je viens de jeter un coup d'oeil dans la documentation, il semblerait que le partitionnement sous PostgreSQL ne soit pas encore disponible par rapport aux autres SGBD.
Il existe bien un partitionnement, mais "par héritage de table", malheureusement ça a l'air assez naze par rapport à la concurrence.
J'ai trouvé un draft ici : https://wiki.postgresql.org/wiki/Table_partitioning . Si vous avez des infos concernant une futur implémentation du partitionnement des tables sous PostgreSQL n'hésitez pas 
Hors ligne
Je viens de jeter un coup d'oeil dans la documentation, il semblerait que le partitionnement sous PostgreSQL ne soit pas encore disponible par rapport aux autres SGBD.
Il existe bien un partitionnement, mais "par héritage de table", malheureusement ça a l'air assez naze par rapport à la concurrence.
Tout à fait, malheureusement.
Cela dit, dans ce cas précis le paritionnement limité possible sous postgres aurait parfaitement fonctionné.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour guk92,
La solution que tu m'as proposé me convient parfaitement.
Merci pour ton aide.
Hors ligne
