<?xml version='1.0' encoding='utf-8'?>
<schedule><version>Firefly</version><conference><title>pgDay Paris 2016</title><start>2016-03-31</start><end>2016-03-31</end><days>1</days><baseurl>https://www.postgresql.eu/events/pgdayparis2016/schedule/</baseurl></conference><day date="2016-03-31"><room name="Other"><event id="1253"><start>08:30</start><duration>00:30</duration><room>Other</room><title>Accueil</title><abstract /><url>https://www.postgresql.eu/events/pgdayparis2016/schedule/session/1253/</url><track>Breaks</track><persons /></event><event id="1254"><start>09:00</start><duration>00:15</duration><room>Other</room><title>Ouverture</title><abstract /><url>https://www.postgresql.eu/events/pgdayparis2016/schedule/session/1254/</url><track>pgDay</track><persons /></event></room><room name="Auditorium"><event id="1221"><start>09:15</start><duration>00:50</duration><room>Auditorium</room><title>Historique des Bases de Données, au regard des exigences actuelles</title><abstract>D'ou viennent les SGBDs actuels ? De la recherche aux
applications ; Qu'est-ce qu'une base de données ? relationelle,
objet, document ?

Le "BigData" remet-il en cause les fondations de nos outils.

Les mathématiques et la recherche universitaire ont permis le
développement des systèmes de gestion des base de données. Retour
historique sur ce qui fonde nos outils :

 * De Codd à jsonb, bases de données relationelles et objets
 * Théorie mathématiques, application informatique
 * Qu'apportent les nouveaux outils (MongoDB …)
 * N'avons nous pas plutôt besoin d'un SGBD souverain ?

La recherche universitaire a apporté les fondations des outils
actuelles, et fourni toujours des applications, y compris dans
PostgreSQL. Et en France ?</abstract><url>https://www.postgresql.eu/events/pgdayparis2016/schedule/session/1221/</url><track>pgDay</track><persons><person id="329">Sébastien Lardière</person></persons></event></room><room name="Other"><event id="1255"><start>10:05</start><duration>00:25</duration><room>Other</room><title>Pause</title><abstract /><url>https://www.postgresql.eu/events/pgdayparis2016/schedule/session/1255/</url><track>Breaks</track><persons /></event></room><room name="Auditorium"><event id="1237"><start>10:30</start><duration>00:50</duration><room>Auditorium</room><title>PostgreSQL Backups the modern ways</title><abstract>There have been many different ways to take backups of PostgreSQL systems over the years, and the tools to do so have evolved both inside PostgreSQL and as addons.

Are you using pg_dump for backups? Calling pg_start_backup()? Writing an archive_command? Then you're probably missing out on new features, and possibly even risking your backups.

In this talk we'll go through the "right" way to do backups on modern versions of PostgreSQL, both using builtin tools and proven external utilities.</abstract><url>https://www.postgresql.eu/events/pgdayparis2016/schedule/session/1237/</url><track>pgDay</track><persons><person id="1">Magnus Hagander</person></persons></event><event id="1234"><start>11:30</start><duration>00:50</duration><room>Auditorium</room><title>Survivre à une migration de données de MySQL vers Postgres</title><abstract>Dans le monde du web, les technologies vieillissent vite et les applications suivent. C'est en général quand le tas de code qui tourne en production montre des signes évident de faiblesse sans qu'aucun remède ne lui rende performance ni stabilité qu'on songe enfin à le ré-écrire. 
Si on peut jeter le code à la poubelle et repartir d'une page blanche, personne n'ose en revanche imaginer qu'on fasse de même avec les données longuement accumulées. 

Cette session est un retour d'expérience de la migration d'un schéma MySQL vers une nouvelle structure en PostgreSQL. </abstract><url>https://www.postgresql.eu/events/pgdayparis2016/schedule/session/1234/</url><track>pgDay</track><persons><person id="207">Grégoire HUBERT</person></persons></event></room><room name="Other"><event id="1257"><start>12:20</start><duration>01:40</duration><room>Other</room><title>Déjeuner</title><abstract /><url>https://www.postgresql.eu/events/pgdayparis2016/schedule/session/1257/</url><track>Breaks</track><persons /></event></room><room name="Auditorium"><event id="1235"><start>14:00</start><duration>00:25</duration><room>Auditorium</room><title>Quels outils de supervision pour PostgreSQL ?</title><abstract>La communauté PostgreSQL regorge d'outils open source pour visualiser et analyser l'activité d'une instance PostgreSQL : que ce soit avec des outils de supervision générique comme nagios ou munin, avec des analyseurs a posteriori comme pgBadger, des outils en ligne de commande comme pg_activity ou des systèmes de visualisation en temps réel PGObserver.......

Même si ces outils sont souvent complémentaires, les utilisateurs de PostgreSQL ont souvent l'embarras du choix... Cette présentation donne les clés pour faire son choix et mettre en place un suivi efficace de PostgreSQL</abstract><url>https://www.postgresql.eu/events/pgdayparis2016/schedule/session/1235/</url><track>pgDay</track><persons><person id="114">Damien Clochard</person></persons></event><event id="1230"><start>14:35</start><duration>00:50</duration><room>Auditorium</room><title>10 Things, an Oracle DBA should care about when moving to PostgreSQL</title><abstract>Oracle DBAs usually have some habits, rules of thumb and best
practices. Not all of them can be applied to PostgreSQL directly. That
can be confusing, however the difference is not so dramatical as it
looks like. It this talk I'll give 10 advices, how transfer your
Oracle knowledge to PostgreSQL, set up the system properly, build a
robust backup-recovery solution and be ready to troubleshoot it.</abstract><url>https://www.postgresql.eu/events/pgdayparis2016/schedule/session/1230/</url><track>pgDay</track><persons><person id="88">Ilya Kosmodemiansky</person></persons></event></room><room name="Other"><event id="1256"><start>15:25</start><duration>00:25</duration><room>Other</room><title>Pause</title><abstract /><url>https://www.postgresql.eu/events/pgdayparis2016/schedule/session/1256/</url><track>Breaks</track><persons /></event></room><room name="Auditorium"><event id="1249"><start>15:50</start><duration>00:50</duration><room>Auditorium</room><title>Tout sur les index</title><abstract>PostgreSQL fournit plusieurs solutions d'indexation : entier, chaine texte, date, tableau, numéros de téléphone, coordonnées GIS, JSON, … à chaque type de données ses spécificités. Et plus encore !
</abstract><url>https://www.postgresql.eu/events/pgdayparis2016/schedule/session/1249/</url><track>pgDay</track><persons><person id="57">Cédric Villemain</person></persons></event><event id="1226"><start>16:50</start><duration>00:20</duration><room>Auditorium</room><title>PostGeol: une (future) extension PostgreSQL pour les géologues, dans le cadre de GeolLLibre</title><abstract>#Geolllibre
Présentation du projet *GeolLlibre* (géologie logiciels libres), qui ambitionne de faire un ensemble logiciel Libre s'articulant autour des métiers des Sciences de la Terre.

##Historique:
###Projet démarré fin 2008.
Lancement de l'idée, partant d'un constat de vacuité:
http://pierremariechevalier.free.fr/pierre_chevalier_geologue/geolllibre/geolllibre_annonce.html
Fondation d'une petite communauté, essentiellement des géologues.
###Une liste de discussion lancée début 2009
Liste de diffusion geolllibre,
Pour s'inscrire : mailto:geolllibre-request@ml.free.fr?subject=subscribe

##Bilan au bout de ... 7 ans déjà
Sans faux-semblant: critique.
###Positif
####TecTri a son code libéré!
Du vieux code VB3, licence similaire à du DSSL.
TecTri est un projet de logiciel d'aide au géologue structuraliste, projet que j'avais lancé suite à un besoin personnel, en 1988, développé ex nihilo en QuickBasic, début de traduction en C, puis repassé en VisualBasic. Projet mené de A à Z, jusqu'à la commercialisation et au support technique.
####Une base de données implémentée sur postgres
BD se voulant la plus générique possible.
Base utilisée en production sur des sites industriels, dans des conditions parfois étranges et éloignées de l'état de l'art en matière de propreté informatique.
Robustesse incomparable du couple Debian/PostgreSQL, malgré des conditions parfois épouvantables (crash serveur plusieurs fois par jour suite coupures de courant dans conditions d'après-guerre).
Ensemble de scripts tournant autour de la base: génération de rapports, mises à jour par calculs implémentés en externe, aller-retours entre d'autres formats (sqlite provenant de logiciel métier par exemple).

###Négatif
####Le code de TecTri n'a attiré aucun contributeur
Il y a des raisons: code en VB3 (...), les portions les plus anciennes du code datent de 1988, une approche spaghetti très criticable, une séparation MVC avant l'heure.
####Manque d'entrain de la communauté
La liste de discussion est régulièrement moribonde, et/ou tourne souvent au soliloque.
####Solitude, parfois...

#Relance du projet, en repartant de la *base*
 =&gt; modèle de données
  =&gt; *base* de données 
   =&gt; *PostgreSQL* naturellement
    =&gt; *PostGeol*!

Il y a de l'existant, une base utilisée en production quotidiennement. Elle est assez adaptée à de la géologie de terrain pragmatique et à de la géologie appliquée en exploration minière.
Décision d'orienter cela vers une *extension PostgreSQL*, avec bien sûr une orientation GIS immédiate par le biais de PostGIS, et une orientation 3D à terme, en visant notamment Paraview et/ou ParaviewGeo, ou des modélisateurs comme blender.

Il n'y plus qu'à...</abstract><url>https://www.postgresql.eu/events/pgdayparis2016/schedule/session/1226/</url><track>pgDay</track><persons><person id="330">Pierre Chevalier</person></persons></event></room><room name="Other"><event id="1258"><start>17:10</start><duration>00:10</duration><room>Other</room><title>Clôture</title><abstract /><url>https://www.postgresql.eu/events/pgdayparis2016/schedule/session/1258/</url><track>pgDay</track><persons /></event></room></day></schedule>