Questionnement : taille de la DB lors de la migration.

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:

---

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)

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é.

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

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 ?

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 :

Citation:

---

- 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.

Citation:

---

- 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.

Citation:

---

- 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.

Citation:

---

- 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.

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 !

Bonjour,

Si cela peut vous aider voici quelques pistes :
-PostgreSQL est open source, gratuit ce qui n'est pas le cas de MySQL bien que l'idée soit répandue.
-MySQL est "plus rapide" sous certaine condtions que Postgres sous faible concurrence et faible volume (pas trop sur quels paramètres prendre).
-Il y a également d'autres SGBDR dont Firebird
-Vous avez l'option payante SQL Server, Oracle.
-Concernant une "liaison plus rapide" je ne vois pas les solutions que vous avez en tête.

D'après mon expérience sur votre cas n°1 :

Citation:

---

d'abord uniquement les données et liaison ODBC avec mon frontal access

---

J'ai d'abord crée ma BDD, puis je l'ai implanté sous Access. Ensuite j'ai crée mon application. Elle était lors de la conception "lié" à Access. Déjà les lenteur survenaient. Une fois le tout mis en réseau il fallait ajouter le temps de latence (certes minime mais pas favorable).

Sur votre choix de langage vous penchez sur du natif ou du managé?
-natif : C/C++-> libre niveau mémoire, vous contrôlez tout et c'est plus dur. Vous avez aussi Delphi mais il faut une version pro pour exploiter les bases de données.
-managé : Java, C# -> ils se valent aujourd'hui (C# a été crée avec moins de défaut que Java mais il n'est optimisé que sous Windows bien qu'il existe Mono sous linux).

Après si vous avez d'autres langages en tête je peux regarder cela.
Vous pouvez me MP au besoin.

Dans votre situation j'opterais pour la stratégie suivante : vous analysez la BDD pour voir si vous pouvez améliorer la conception de celle-ci (normalisation, type de données, requête SQL). Ensuite vous estimez le temps que vous mettrez à migrer le tout sous une BDD dédiée (dans votre cas PostgreSQL semble être la meilleure option gratuite). Cette étape est très importante car elle est le coeur de votre projet. Une BDD mal faite donne de mauvaises performances malgré un code excellent.
Enfin selon le temps restant vous choisissez votre langage. Selon moi, il vaudrait mieux en prendre un que vous connaissez.

Encore merci pour vos réponses

Cordialement,
0x

Merci pour ces conseils !

Je continue sur le forum au cas où ça en intéresse d'autres ;)

J'ai migré sans trop de difficultés ma base de données vers PostGre et vers SQL server express
Ensuite j'y ai connecté ma frontale via une liaison ODBC et j'en ai profité pour développer un module qui permet à ce frontale de se connecter à n'importe quel type de base

Jusque là tout va bien, malheureusement - en monoposte - les temps de réponse sont meilleurs avec ma base Access :(

Ensuite j'ai envisagé de réécrire les modules les plus lents en VB.net avec une connexion ADO car j'avais lu que c'est plus performant. Mais pour cela il faut tout réécrire et dans ces conditions VB.net n'a plus rien à voir avec VBA tel que je l'utilise depuis 5 ans !!! En plus je n'ai pas réussi à connecter PostGre à .net et je n'ai trouvé aucune aide sur les forums postGre alors que cela me semble élémentaire mon cher Watson !

C'était il y a 6 mois et depuis je tergiverse : fonctionnellement je sais ce que je veux faire mais techniquement je ne sais pas quels sont les outils les mieux adaptés...