Programmer une extension de Postgresql, que choisir

[ymoreau]

Bonjour, je dois programmer des traitements assez complexes (parcourir du XML, travailler sur du texte, avoir des listes et des maps). Certains points du projets ont besoin de performances, tandis que d'autres auraient surtout la priorité sur une facilité à être relus/repris et évoluer.

Pour le moment j'ai travaillé avec pl/pgsql et des scripts ruby clients. J'aimerais avoir des avis sur les différentes possibilités. J'imagine que les extensions C sont les plus performantes, mais on m'a également dit qu'il est assez compliqué d'y gérer les caractères spéciaux, encodages etc. Je ne connais ni le perl ni le python, est-ce qu'il y a une grosse différence de performances par rapport au C, puis au pl/pgsql ? et est-ce que ces langages au sein postgresql sont réduits par rapports à leur version normale ? (surtout pour le XML et les chaînes)
Ça ne me dérangerait pas d'utiliser plusieurs langages pour les différentes procédures, selon le besoin de performance/lisibilité.

Et enfin, est-ce que tout faire en procédure dans postgresql n'est pas trop contraignant par rapport à une appli cliente (qui pourrait être développée en langage objet).

Merci d'avance !

[kain_tn]

Bonjour,

pour ce qui est des performances du C face au PL/pgSQL, elles peuvent être assez importantes en fonction de ce que tu fais.

Maintenant, peut-être que tu peux décomposer le travail et faire des petites fonctions "bas niveau" en C et les utiliser dans des fonctions PL/pgSQL pour la lisibilité et les modifications.

Pour ce qui est de la programmation Unicode en C, elle n'est pas liée à PostgreSQL mais au C. Il y a un lien sur stackoverflow assez intéressant sur le sujet: http://stackoverflow.com/questions/5...am-for-unicode.

L'intérêt d'utiliser des procédures stockées vs du code client c'est de centraliser le code métier quand tu as des clients hétérogènes (plusieurs services qui font la même chose ou presque, du code écrit dans différents langages, etc...), de réduire la taille et le nombre de requêtes qui passent du client au sgbd, d'accélérer les traitements (oui, le PL/pgSQL est pré-compilé) vs du SQL classique, d'effectuer du typage et des transactions (même si tout ça peut-être fait via odbc/jdbc), etc...

Bref, je dirais que c'est à choisir au cas par cas. Si les traitements que tu compte faire sont lourds et peuvent être faits hors de la base de données, c'est mieux car c'est souvent plus facile et moins cher de rajouter des machines qui effectuent ce traitement que de dimensionner la base de données pour prendre tout ça dans la g.....

Un dernier point, tu as parlé de travailler sur du texte. Il y a une extension qui peut (ou pas) t'être assez utile là dessus: http://www.postgresql.org/docs/9.0/s...extsearch.html

[ymoreau]

Merci! J'utilise déjà l'extension textsearch.

Je pensais également utiliser le C pour optimiser les procédures de plus bas niveau et soit le pl/pgsql pour le reste, soit le pl/python si le pg ne permet de faire tout ce dont j'ai besoin. Ce qui sera surement le cas, car j'utilise des listes chaînées, peut être des hashmaps.

C'est vrai que laisser les gros traitements côté client permet de les faire tourner sur d'autres machines, d'un autre côté le gain que l'on a en évitant les connexions et les requêtes client/serveur peut vraiment valoir le coup, au moins pour une partie de mes fonctionnalités.

Merci pour le lien sur la discussion de l'unicode en C !