Bonjour,
je vais devoir aider � la migration de Microsoft Access � PostgreSQL. Je
m'adresse � la liste pour prendre la temp�rature et voir quelles sont les
meilleures solutions en ce moment. La raison de la migration est
principalement la performance: actuellement seuls deux clients acc�dent �
la base de donn�es (en recording locking sur un serveur SMB Windows NT),
et c'est d�j� tr�s lent, il est pr�vu de passer � beaucoup plus de
clients. La seule contrainte est que comme de nombreux
scripts/forms/report ont �t� r�alis�s en Microsoft Visual Basic, on ne
peut se passer du client Microsoft Access.
Je ne connais pas Microsoft Access, mais d'apr�s ce que j'ai compris, il
ne semble pas possible d'utiliser ce logiciel en mode serveur (requ�te
p.ex. ODBC depuis des clients l�gers), on peut soit acc�der � la base de
donn�es en exclusif, soit utiliser du record locking (probablement bas�
sur les oplocks), mais dans les deux cas il faut un serveur de fichiers
compatible SMB.
Les possibilit�s que j'entrevois au niveau des am�liorations possibles
pour augmenter la performance:
- passer le r�seau � une plus grande vitesse
(je n'y crois pas trop, en plus ma philosophie client/serveur de
base de donn�es n'est pas du partage de fichiers)
- booster le serveur de fichiers Microsoft Windows NT
(m�me raison, en plus je voudrais m'en d�barrasser)
- mettre un des postes client comme serveur ODBC Microsoft Access,
ainsi toutes les requ�tes SQL des clients sont ex�cut�es dessus.
(je ne crois pas cela possible avec Microsoft Access)
- migrer le fichier sur un serveur Linux haute performance
(co�t plus faible en mat�riel/logiciel que Microsoft Windows NT,
mais � mon avis cela ne r�soudra pas le probl�me de performance,
et cela risque d'ajouter de nouveaux probl�mes: d'apr�s ce que
j'ai vu sur des mailing-lists, les oplocks semblent ne pas �tre
bien fiables avec Samba + Microsoft Access, commentaires ?)
- utiliser la couche ODBC de Microsoft Access, en conservant tout le
processing local (Microsoft Visual Basic), seules les requ�tes SQL
traversent le r�seau, sur un serveur PostgreSQL.
(mes soucis: 1. exportation de la base
2. compatibilit� et fiabilit� de ODBC + PostgreSQL
3. rapidit� du serveur PostgreSQL (des essais que
j'avais fait il y a longtemps avaient montr� que
pour des requ�tes SQL assez simple, PostgreSQL
semblait battre, et de loin, Microsoft Access,
m�me sur une configuration ridicule. Mais qu'en
est-il `en vrai' ?)
4. co�t de la licence ODBC sur chaque client)
On peut alors se d�barrasser aussi du serveur de fichiers.
J'ai exclu de passer sur un client non Microsoft Access pour les raisons
expliqu�es ci-dessus (mais cela pourrait se faire en deuxi�me �tape si le
client est content de sa solution et veut investir du temps � porter ses
scripts et son environnement en open source, pour se d�barrasser des
licences Microsoft Access, ODBC, voire Microsoft Windows si une solution
compl�tement libre est possible, p.ex. avec le futur Star Office open
source).
Commentaires sur ce qui pr�c�de ? Avez-vous d�j� mis en oeuvre une telle
chose ? Quels sont les �cueils ? Merci de tout commentaire.
Pendant que j'y suis, les fonctionnalit�s suivantes semblent �tre pr�vues
pour la prochaine version de PostgreSQL, certaines sont d�j� pr�tes mais
doivent �tre test�es. Excitant, non ?
- log all transactions to a special log file, that can be used for
backup purposes: ie you dump the database every day, but you keep
the transaction log on a separate disk. Should the database disk
crash, you won't have any data loss if you restore the backup and
replay the transaction log.
(pr�vu bient�t)
- hard transactions: cutting the power to a PostgreSQL server
may cause data loss and/or data corruption. Some databases use
sophisticated techniques to ensure serialization of operation
through journaling, redoing some of the transactions at
bootup time if required.
(d'apr�s les d�veloppeurs, partiellement bon avec support fsync()
enclench�, et d�coule du premier point pour le reste)
- the ability to synchronize two database servers, with only the
changes being exchanged, live. Or the ability to have many
servers in a load-balancing or data scattering pool.
(en cours de r�alisation: http://www.erserver.com/)
- ability to have databases bigger than the host's maximum file size
(d�j� bon: PostgreSQL utilise des spools de 1 GB)
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.
