Questionnement sur une migration MsSQL > PostGreSQL [Résolu]

[Jsh]

Bonjour,

Dans un souci de rationalisation des couts (en d'autres termes : "c'est cher les licences !"), notre équipe a décidé dans le cas de l'exploitation d'un site intranet Asp .Net de se tourner vers PostGreSQL.

Voici quelques soucis que nous avions pu rencontrer avec MsSQL :

- dépassement des pools de connexion (résolu sous IE avec un bon nettoyage de pools et une recherche méthodique des connexions non fermées, mais semblant subsister sous Firefox), mais combien de connexions pourrait supporter une base sous PostGreSQL
- Champ de VarChar limités à 8000 caractères (j'ai lu dans la FAQ PostGreSQL qu'un champ de texte peut aller jusqu'à 1Go)

Risquons-nous de rencontrer ce même genre de soucis ?

J'ai commencé à lire l'article sur http://www.postgresql.org/docs/techdocs.29, mais si quelqu'un a déjà effectué ce genre de migration, peut-il me faire un retour d'expérience : difficulté à la mise en œuvre, temps passé, soucis rencontrés, etc.

Je ne pose pas la question sur la compatibilité de nos requêtes, nous allons effectuer des jeux de tests avant la migration

Je vous remercie par avance, en souhaitant de devenir un participant assidu à ce forum, puisque nous désirons fortement cette migration.

[gleu_]

Pour le nombre de connexions, par défaut, PostgreSQL accepte 100 connexions simultanées. Il est possible d'augmenter ce nombre en modifiant le paramètre max_connections. Il est aussi possible d'utiliser des spoolers de connexions (comme pgPool, pgPool II et enfin pgBouncer).

Quant au type chaîne de caractères, il existe deux types : varchar et text. Avec varchar, il est possible de limiter la taille de la chaîne (varchar(50) pour 50 caractères par exemple). Mais il est préférable d'utiliser text. Pas d'inquiétude quant à la longueur du texte (dans la limite de 1Go).

J'ai déjà réalisé une migration de SQL Server vers PostgreSQL et cela ne m'avait pas posé beaucoup de problèmes (la base faisait 4 Go, n'utilisait pas de fonctionnalités très avancées en dehors des procédures stockées qu'il a fallu ré-écrire).

Bon courage

[htristra]

Bonsoir,

utilisateur de mysql depuis la version 3.x pour des bases plus ou moins grosse.
Je gére plusieurs bases pour des clients. Les volumes sont assez variables :
de 10000 contacts à 4 millons d'adresses croisées à 7 millons de noms. La plus grosse base que nous possédons contient 25 millions d'adresses.

J'ai récemment créer une nouvelle base pour la gestion de tickets de caisse. Le volume attendu est d'environ 1 million de tickets par an.

J'ai décidé d'utiliser PostGreSql pour les raisons suivantes :

1. une vrai gestion des triggers
2. un bon plpgsql et la possibilité d'utiliser des fonctions codées en C (mysql aussi) mais également python
3. gestion des intersections/exclusion

J'ai réalisé des tests comparatifs avec la base de 25 millons. Les types de champs et index étaient les mêmes. Pour faire court, pour des requêtes simples de comptages avec justes de conditions d'égalité strict utilisant les index, on ne note pas de différences majeurs.
PostGres commence à prendre le dessus lorsque les requêtes deviennent plus complexes.

Par contre, je ne suis pas certain que Postgres puisse prendre le dessus sur des écritures massives (mes bases mysql sont en myisam et non en inodb), mais cela résulte plus de la gestion des table spaces contre la gestion une table un fichier de mysql.

Pour ma part, je reste pg surtout pour les triggers, fonctions.... la souplesse d'utilisation.

[Jsh]

Un grand merci pour ces réponses qui me donnent déjà pas mal de pistes !

Je mets ce poste en résolu, mais si certains désirent encore y apporter leur contribution, je continue à le surveiller