At 11:02 11.10.2000 +0200, you wrote:
>Bonjour,
>
>je vais devoir aider � la migration de Microsoft Access � PostgreSQL. ...
>
>Commentaires sur ce qui pr�c�de ? Avez-vous d�j� mis en oeuvre une telle
>chose ? Quels sont les �cueils ?
On m'a fortement d�conseill� l'utilisation d'ODBC dans ce cas de figure,
tr�s al�atoire au niveau des performances et d'int�grit� des donn�es.
> Merci de tout commentaire.
C'est marrant, il se trouve que je suis � quelques d�tails pr�t dans la
m�me situation que toi. En effet, une �cole de musique souhaite mettre en
place un syst�me de formation � distance. Ils ont d�j� commenc� � r�alis�
leur base de donn�es, sous Access bien entendu, avec tous les probl�mes qui
en d�coulent et que tu as en gros parfaitement r�sum�s.
En revanche, la solution retenue sera sans doute MySQL + PHP4 pour la
partie information ( plan des cours, etc.. ). Donc vu la situation, et par
rapport aux infos que j'ai r�colt�es jusqu'� pr�sent, il y a des chances
pour que cette base Access tourne directement sur une machine autonome, et
tout ce qui va avec pour la partie formation Web. Ensuite, il s'agira pour
moi de trouver dans quelle mesure je pourrai effectuer un pont entre Access
et MySQL ( import - export ) et assurer l'int�grit� des donn�es qui
passeront de l'un � l'autre.
>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 ?
Y a t-il de gros changements ( ou difficult�s ) pour un utilisateur de
MySQL migrant vers Posgres ?
> - 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.
--
Patrick GONCALVES
Daily-Soft Assistance
[EMAIL PROTECTED]
ICQ : 20057008
http://patg.multimania.com
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.
