Discussion :

[Oxyale]

Bonjour à toutes et à tous,

J'ai entrepris une migration totale d'une base à partir d'Access (2010) installé sur un ordinateur local.
J'ai choisi Postgresql 9.2 installé sur un serveur et après un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT pg_database_size('mabase');

trouvé ici :http://www.developpez.net/forums/d32...-base-donnees/

J'ai aperçu dans la suite de la discussion que j'étais dans le même cas.

Je reste assez surpris. Il se trouve que ma base me prend 136 Mo sous Access/Windows et 8Mo sous Postgresql/Linux.

Ma db contient que quelques tables dont une d'un peu plus de 17500 entrées.

Voilà ma question : que justifie ce rapport de 17?

EDIT : un petit test sous MySQL m'avait donné une taille totale de 22 Mo soit un rapport de 6 avec Access. (à prendre avec des pincettes)

[punkoff]

Bonjour,

17500 lignes ca ne veux pas dire grand chose.

Prenez une table avec 2 colonnes de type numeric (longueur d'un integer) mettez 1 million de lignes et elle ne fera que dans les 15mo.

Vous pouvez faire une estimation de la taille de votre base en connaissant les types des colonnes qui sont dans vos tables.

Pour les index c'est un peu plus compliqué.

Sinon via pgAdmin, si vous avez fait un "analyze" de votre base, vous aurez des données sur la taille actuelle de vos tables / indexs.

Pour cette commande en particulier je ne l'ai jamais testé.

[Oxyale]

Bonjour,

En premier lieu, merci d'avoir pris la peine de m'avoir répondu.

En effet, 17000 lignes c'est très peu, c'est pour cela que je suis surpris de voir une si grande différence. Cela n'était qu'un échantillon de test avant de tout migrer (plusieurs bases Acess contenant des tables de quelques centaines de milliers de lignes chacune).

Je parlais de ces 17000 car dans cette base Access j'ai estimé que cette table était bien représentative pour un premier test dans PostgreSQL.

Lorsque je vois dans cette base Access contenant 4 tables dont la plus grosse est celle dont on parle : 136 Mo et 8Mo sous postgres je me pose la question comment Access fonctionne car je doute que ce soit cela qui justifie cette taille sur disque.
Cette table de test ne contient que 6 champs : 1 integer, 5 varchar sous Access . Rien de bien compliqué pour justifier autant de poids

[nico84]

Bonjour,

La base access a-t-elle été compactée ? Il m'est arrivé de voir la taille d'une base diviser par 100 par cette simple opération...

Par ailleurs je suis intéressé par un retour d'expérience sur cette migration que j'envisage aussi :
- en quel langage est le logiciel qui exploite la base ? Access ?
- pourquoi cette migration ?
- quelle connexion entre le logiciel et postgre ? ODBC ?
- y a-t-il un gain en temps de réponse ?

[Oxyale]

ReBonjour,

Vous aviez raison, le poids de la base a bien fondu comme neige au soleil : elle est passé à 3Mo.

Pour vos questions : c'était un projet pour une TPE. Cela est aujourd'hui un projet personnel que je vais entreprendre sur mon temps libre (car cela peut servir plus tard) mais je peux vous donner les premières réponses si cela vous convient :

- en quel langage est le logiciel qui exploite la base ? Access ?

La premère application était écrite en C# (version 3.0 plus exactement). En somme elle consistait à automatiser les opérations de mailing de la structure et facilitait leur ciblage. Elle fonctionnait grâce à l'API d'Access.

- pourquoi cette migration ?

Durant son développement, il y avait deux inconvénients : le premier était que l'application était en locale uniquement sur un ordinateur (donc une bdd unique avec tout les risques liés à la corruption de la base, panne du matériel etc...), le second était que cette application ne gérait pas le retour des mails (notamment savoir si les emails avaient bien été lus), cet inconvénient découle du premier (après une petite recherche il faut scripter sur ce point).
C'est pourquoi je souhaite tout migrer vers une architecture découpé en :
-un serveur avec une base de données. Dans mon test il y aura deux tables (une de 100.000 et une de 500.000) contenant les coordonnées professionnelles et ces deux tables seront "reliées" à des tables concernant leur position géographique sur le territoire (la ville, le département, la région) pour un ciblage. Dans la partie finale, je pense n'en garder qu'une mais elle pourra devenir critique.

-un serveur d'application développé en JavaEE de sorte que toute la structure pourra en profiter "à distance". De plus je pourrais gérer la partie script nécessaire au retour d'expérience du mail.

- quelle connexion entre le logiciel et postgre ? ODBC ?

Cette connexion sera réalisé avec JDBC. Auparavant, la connexion en c# se faisait par l'intermédiaire du composant OleDB.

- y a-t-il un gain en temps de réponse ?

Sur ce point je ne peux vous apporter une réponse immédiate : je risque d'être un peu thérorique.
Concernant l'application lourde il y avait un temps de latence très perceptible lorsque nous sollicitions la base Access. Cette solution fonctionne très bien et il n'y a pas de problèmes (juste quelques secondes mais trop lent vu la taille minime de la base). J'ai repris le projet dans le but de résorber cette latence et in fine avoir un applicatif accessible n'importe où.

Au cas où j'ai d'abord soupçonner mes tables et comment elles ont été faites : que des tables modérément normalisées (enfin pour ce qu'il y a à normaliser^^) avec des integer et des varchar sous Access -> Sous Postgres je vais essayer de la rendre un peu plus propre de sorte qu'il y ait une intégrité référentielle.

Je reviens donc sur la partie théorique : le temps gagné par la meilleure conception de la bdd et de la gestion des données de Postgres risque d'être modéré par la latence du réseau.
A vérifier.

Si cela peut vous aider, c'est un réel plaisir.

[nico84]

Merci pour cette réponse détaillée !

Finalement la base est 3 fois plus grosse avec postgre et 7 fois plus avec mysql, avantage à postgre donc

J'envisage de migrer une grosse application pour PME car Access est trop lent en multiposte :
- d'abord uniquement les données et liaison ODBC avec mon frontal access
- ensuite réécrire le logiciel dans un autre langage et avec une liaison plus rapide

Mais je n'arrive pas à me décider ni pour le choix de la base ni pour le choix du langage d'où mes questions !