Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#26 Re : Général » Des termes à éclaircir... » 05/06/2013 09:25:23
Bonjour,
C'est bien cela.
Votre interprétation est la bonne.
#27 Re : Général » Des termes à éclaircir... » 04/06/2013 18:14:32
La table référençante est la table intervention, qui référence la table camion.
La table référencée est la table camion.
La colonne référencée est la clé primaire de la table camion, soit la colonne camion.cam_id.
Les lignes référencées sont celles de camion pour lesquelles on trouve intervention.int_cam_id=camion.cam_id.
Les lignes de la table intervention référencent celles de camion.
Est-ce plus clair ?
#28 Re : Général » Problème clés étrangères » 04/06/2013 12:13:06
Que donne un \dt+ sur votre base ?
#29 Re : Général » Problème clés étrangères » 04/06/2013 11:52:58
Bonjour,
Toutes vos tables sont-elles créées dans le même schéma ?
Est-ce le même utilisateur qui possède les relations, et les crée ?
#30 Re : PHP » Contraintes de clés étrangères vs. vérifications PHP » 04/06/2013 08:32:40
Bonjour,
C'est une erreur répandue que de penser que l'intelligence ne se trouve que dans l'applicatif.
Une réflexion bien menée du côté du schéma de la base vous permettra d'éviter bien des soucis ultérieurs.
La vérification des contraintes au niveau base ne vous empêche pas de valider en amont côté applicatif, mais évitera qu'une erreur applicative ne corrompe vos données.
#31 Re : Réplication » transferer des tables vers un autre serveur postgresql » 31/05/2013 22:14:17
Vous pouvez également envisager une réplication de la table.
Il vous faudra néanmoins avoir défini la structure de la table dans la base cible.
#32 Re : Général » Type pour un intervalle de temps » 29/05/2013 16:46:28
Tiens, un spammeur...
#33 Re : Offres » [CDI][Paris] expert PostGreSQL - DBA Etudes & Développement » 29/05/2013 16:45:16
Qu'est-ce qu'un salaire de ministre ?
Le salaire proposé est pourtant intéressant.
Il est plus élevé que ce que proposent nombre de SSII pour ce genre de poste.
#34 Re : PL/pgSQL » order by sur un champ non sélectionné » 29/05/2013 16:43:04
Bonjour,
Il n'est pas nécessaire d'afficher le champ sur lequel porte le tri.
select C4 from votre_table order by C3;
doit vous retourner l'adresse triée par le nom de la voie.
#35 Re : Optimisation » [v9.2] Performances en lecture faible sur 25M de lignes, étrange ? » 16/05/2013 15:03:39
Bonjour,
L'index ne sert à rien dans ce cas précis, puisque vous récupérez l'intégralité des données, pour les regrouper par année.
Vous lisez 25M de lignes pour n'en afficher que 15.
#36 Re : Site PostgreSQL.fr » Syntaxe des messages sur le forum » 16/05/2013 09:49:08
Je conseille donc vivement à tout le monde de :
1. faire des phrases (avec la ponctuation appropriée)
2. se relire afin de vérifier que les phrases en question sont compréhensibles (simplifier éventuellement),
3. passer éventuellement le texte au vérificateur d'orthographe.
C'est malheureusement le cas également des courriels sur les listes de diffusion, ou des billets sur le blog.
#37 Re : Site PostgreSQL.fr » Syntaxe des messages sur le forum » 16/05/2013 09:47:22
J'ai la vague impression que SFGSAFSF est un compte parasite.
#38 Re : Site PostgreSQL.fr » Certification PostgreSQL » 14/05/2013 15:19:25
Dans les organismes de formation, on trouve également Loxodata.
#39 Re : Installation » Problème installation PG 8.4.1 - répertoire data » 25/10/2011 12:29:59
D:\data_pg_84 ?
#40 Re : Général » Creation d'un dump de postgresql depuis une application web » 25/10/2011 12:17:55
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trustAvec ces entrées, cela fonctionne. Par contre, pour les connexions IPv6, si je mets "md5" ou "password" ou que je désactive l'entrée, cela ne fonctionne plus.
On dirait que c'est la partie IPv6 qui prime ???ps : Ces entrées avec la méthode md5 ou password et un fichier pgpass.conf ne fonctionne pas !!
Qu'avez-vous comme entrée pour les connexions locales ?
Quelle est votre chaine de connexion ?
#41 Re : Installation » Installation option DBLINK sur Postgresql 9.1 RC1 » 25/10/2011 12:10:18
Bonjour,
PostgreSQL 9.1 a été publiée en version finale il y a quelques semaines.
Je vous déconseille fortement de continuer à utiliser la RC1.
#42 Re : Réplication » Connection lente » 25/10/2011 10:18:10
Bonjour,
Il me semble que la solution la plus adaptée est Slony, puisque c'est actuellement une des seules solutions à proposer le cascading.
Vous pouvez éventuellement regarder Tungsten replicator et SymmetricDS.
#43 Re : Optimisation » [Table Enormes] Demande de renseignements / 'Best practices' » 11/10/2011 10:49:03
- L'existant: nous avons un PostgreSQL configuré à la Warrior, avec des stored procedure et 25 tables de 100KB à 1MB, sauf une (les paquets) qui fait + d'une 20aine de GB (réparti 50-50% entre la Table Size et l'indexes Size), avec seulement 6 champs pourtant.
Les requêtes SQL sont actuellement faites maison avec PHP, une vilaine couche d'HTML et le tout servi en graphiques SVG (à abandonner au plus vite)CREATE TABLE packets
(
pkid bigserial NOT NULL,
flid smallint,
pktime timestamp without time zone,
pksig bytea,
pksize smallint,
pkflag character(1),
CONSTRAINT packets_pkey PRIMARY KEY (pkid),
CONSTRAINT packets_flid_fkey FOREIGN KEY (flid)
REFERENCES flows (flid) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE CASCADE,
CONSTRAINT packets_flid_key UNIQUE (flid, pktime, pksig)
)
Vous pouvez probablement envisager un partitionnement au niveau du pktime. Voire un archivage des données vers une table qui ne serait accéder qu'en cas de besoin d'informations plus anciennes.
#44 Re : Général » PGPOOL commencement » 04/10/2011 12:09:23
1°) Quand vous parlez de PGPOOL avec Slony, on est bien d'accord que c'est du triggering entre le maitre et l'esclave (Une modifications de données du maître envoie la même modification (via un trigger) vers l'esclave)... me trompe-je ?
pgpool et Slony sont deux outils indépendants. Pgpool peut s'appuyer sur Slony pour faire de l'équilibrage entre le maître et l'esclave, mais c'est Slony qui assure la réplication.
Slony est un outil de réplication asynchrone asymétrique. Il fonctionne effectivement à base de triggers.
Asynchrone : les données sont propagées sur l'esclave indépendamment de leur enregistrement sur le maître.
Asymétrique : la réplication ne s'effectue que dans le sens maître -> esclave.
2°) Est-ce ça que vous appelez le 'synchrone asymétrique'
Synchrone : l'écriture sur le maître s'effectue après la validation de l'écriture sur l'esclave. Principe existant sur PostgreSQL 9.1 en streaming replication.
#45 Re : Optimisation » [Table Enormes] Demande de renseignements / 'Best practices' » 04/10/2011 10:42:18
I. La structure de la DB:
a.) Le choix de PostgreSQL jsutement: est-ce que les outils libres SQL sont valables?
Oui.
Et vous pouvez également prévoir de partitionner vos tables pour éviter qu'elles ne grossissent démeusurément.
b.) L’agrégation justement: bien que je ne l'ai jamais fait, il semble que l'on peut rendre une DB 'vivante' avec des triggers et des nested routines, qui spontanément vont faire du 'house-keeping' des données, soit directement à l'insert, soit plus tard, selon une date/durée d'expiration.
Est-ce intéressant? efficace? Mieux vaut tout laisser en granularité maximale et laisser la partie 'query & display' faire les arrangements?
Est-ce franchement abérant de vouloir tout mettre dans une table? mieux vaut passer à une table par jour et possibilité de 'LEFT JOIN' si jamais on fait des recherches sur une nuit qui couvre 2 tables?
Cela dépend grandement de la présentation que vous voulez faire de vos données. Si de gros calculs sont à prévoir pour les afficher, il sera préférable d'envisager de les calculer préalablement. Tiggers, cron... à vous de voir.
II. Le support HW:
c.) Bien que l'idée soit de partir d'un serveur "moyen" ici sous la main (raid-SAS, 10aine de Go RAM, 4/8 cores), je me demande s'il y a moyen de gagner en I/O autrement.
J'ai découvert (ici même) qu'il y avait moyen de balancer toute la DB en RAM au boot. Malin? Bricolage? limitation?
Est-il possible de ne mettre en RAM unquement qu'une partie (table des données du jour, par ex.) ?
Y a-t-il des nouvelles révolutions en la matière? (les fameux clouds? le faite de taper 2 de nos serveurs ensemble, en //?)
On peut envisager de nombreuses méthodes d'accélérer les accès. Si votre serveur est fourni en RAM et la volumétrie faible, le cache système jouera.
Ensuite, vous pouvez prévoir de travailler en RAM, mais un crash du serveur, et vos données se volatilisent...
III. L'extraction des données:
d.) Ecrire sa propre petite librairie PHP pour faire des requêtes SQL semble un sport spécifique et pourtant rendu très automatique par les ORM/DBAL en PHP: je me dis que cette communautée a certainement plus d'expérience que moi (même si je fait du PHP/SQL depuis +/-8ans) et que leur requêtes générées seront plus optimisées. Mais tiendront-elles compte de la taille de mes tables?
Est-ce vraiment la panacée dans mon cas?
Le sirop Typhon, en terme de requêtes, est probablement à éviter. Un oeil qui connaît les tables et leur volumétrie a toujours sa place dans le développement des requêtes.
#46 Re : Réplication » Slony et log Shipping » 23/09/2011 09:39:01
Bonjour,
Pour se simplifier la vie avec Slony, il existe les outils d'administration slony1-ctl : http://slony1-ctl.projects.postgresql.org/.
A l'aide de 3 fichiers de configuration, on peut aisément créer et maintenir une réplication slony.
#47 Re : PSQL » pg_dump » 03/08/2011 11:18:57
Bonjour,
Pour utiliser pg_restore, il faut utiliser un dump binaire. Avec un dump sql, comme produit par pg_dump sans option, il suffit effectivement d'utiliser psql avec l'option -f.
pgadmin utilise les dumps binaires.
#48 Re : Réplication » problème varchar avec slony ? » 22/06/2011 19:10:01
Bonjour,
Un des prérequis de Slony est effectivement que vos bases soient dans des encodages « équivalents ». Latin1 et latin9, par exemple.
En revanche, comme vous l'avez compris, avec de l'utf8, il faut que tous les nœuds soient en utf8.
#49 Re : Réplication » slony replication 1 maitre 2 esclaves avec des schémas différents help » 21/06/2011 15:26:21
Bonjour,
Il existe des paquets RPM de Slony pour RedHat.
Vous pouvez jeter un oeil sur le site http://yum.pgrpms.org.
#50 Re : Réplication » precautions a prendre en vue d'une future réplication des données » 20/06/2011 09:11:02
Bonjour,
Il est possible qu'à l'avenir je veuille avoir une base "décentralisée" sur mon ordi portable, pour pouvoir continuer à travailler même sans connexion sur le serveur.
Quel est le meilleur outil pour gérer la réplication entre le serveur et le portable dans ce cas ? Notamment, je me pose des questions du genre : supposons qu'au moment de la synchronisation, le dernier SERIAL utilisé soit par exemple le n° 1234. Que se passe-t-il si je crée un nouveau tiers sur mon ordi portable (qui aura donc le n° 1235), et que pendant ce temps quelqu'un créé un autre tiers sur le serveur (qui aura donc aussi le n° 1235) ? Que va-t-il se passer lors de la réplication suivante ? Y-a-t-il des outils de réplication qui gèrent automatiquement ce cas de figure, ou bien faut-il prendre d'ores et déjà des précautions dans le choix des clés primaires (par exemple avoir comme primary key une combinaison du serial et du username, ou un truc du genre...)
Bonjour,
A partir du moment où l'ensemble des nœuds n'est pas disponible en continu, il devient ardu de gérer une réplication de type Slony ou réplication interne.
La meilleure solution dans votre cas reste de définir une clé composite, composée de la clé primaire de votre table (séquence), et d'un identifiant du client (idc=1 pour le serveur, idc=2 pour le portable...), et d'associer à vos enregistrements une estampille temporelle de modification.
Ainsi, chaque enregistrement peut être identifié par l'identifiant de ligne et l'identifiant de client, et un groupe date-heure qui vous permet de gérer aisément les conflits avec une règle de type « le dernier qui a parlé a raison », par exemple.