How can I migrate a PostgreSQL database to MySQL or MS Access? Are there any
tools available?
--
View this message in context: http://www.nabble.com/Migrating-Post....html#a5776442
Sent from the PostgreSQL - general forum at Nabble.com.


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

RPK <rohitprakash123@indiatimes.com> wrote:

>
> How can I migrate a PostgreSQL database to MySQL or MS Access?

You can't. Neither MySQL nor Access support the advanced features in
PostgreSQL. You'll probably have to rewrite the app.

--
Bill Moran

Microsoft: Where do you want to go today?
Linux: Where do you want to go tomorrow?
FreeBSD: Are you guys coming or what?


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On 8/12/06, Bill Moran <wmoran@collaborativefusion.com> wrote:
> RPK <rohitprakash123@indiatimes.com> wrote:
>
> >
> > How can I migrate a PostgreSQL database to MySQL or MS Access?

in your case i would suggest ms dts or vb script in conjunction with
the odbc driver for both databases.

> You can't. Neither MySQL nor Access support the advanced features in
> PostgreSQL. You'll probably have to rewrite the app.

well, since he wrote his app in vb.net he is probably using postgresql
as a dumb data store, it might not be all that difficult. still, not a
very smart move.

merlin

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

> well, since he wrote his app in vb.net he is probably using postgresql
> as a dumb data store, it might not be all that difficult. still, not a
> very smart move.
>

so if you have functions on server side or triggers or rules... then
you need some rewrite on the app... otherwise just to adapt the sql as
necessary...

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On 8/12/06, Jaime Casanova <systemguards@gmail.com> wrote:
> > well, since he wrote his app in vb.net he is probably using postgresql
> > as a dumb data store, it might not be all that difficult. still, not a
> > very smart move.
>
> so if you have functions on server side or triggers or rules... then
> you need some rewrite on the app... otherwise just to adapt the sql as
> necessary...

the .net 'way' of database application development is to keep all the
logic in the .net middleware. please note that I am completely
opposed to this because it obfuscates good data management practices.
however based on the op's comments I am guessing he is doing things
the .net way.

merlin

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Merlin,

the .net 'way' of database application development is to keep all the
> logic in the .net middleware. please note that I am completely
> opposed to this because it obfuscates good data management practices.


are you serious and well informed about this? There is really again somebody
throwing away decades of experience, a theoretically proven data integrity
system just to reimplement the wheel in a shiny, unproven technology?

Do you know for what benefit that happens? I have seen similiar stupidity
with EJB, having RI within that layer. Why are people doing this? Do they
know something I miss, or did they just not vivist Databases 101 ?

Harald

--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Reinsburgstraße 202b
70197 Stuttgart
0173/9409607
-
Let's set so double the killer delete select all.

Harald Armin Massa wrote on 13.08.2006 10:46:
> Do you know for what benefit that happens? I have seen similiar stupidity
> with EJB, having RI within that layer. Why are people doing this? Do they
> know something I miss, or did they just not vivist Databases 101 ?

I think this happens because of the OO/UML hype. People tend to see the database
as a mere storage facility and putting the logic (including RI and other stuff)
in the middle tier. This should make the application more platform independent.

I'm a J2EE developer but with a strong database background and I always have to
fight to get the basic checks into the database. Too many people coming from
MySQL, Access and dBase ("but we can check that in the application logic!")

And MS is going the same way I think (haven't done any .net development though,
but seeing SQL Server's transact SQL I really don't want to use that for
implementing my business logic as well

Regards
Thomas


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Kellerer wrote:
> Harald Armin Massa wrote on 13.08.2006 10:46:
>> Do you know for what benefit that happens? I have seen similiar stupidity
>> with EJB, having RI within that layer. Why are people doing this? Do they
>> know something I miss, or did they just not vivist Databases 101 ?

This is RDBMS Conventional Wisdom. Putting lots of logic into the
RDB has it's down-side though: depending on the RDBMS, you might
need an exclusive lock to modify a trigger or CHECK constraints,
drop a stored procedure, etc. If the object is on a popular table,
the whole app system may have to come down.

Next there's maintenance. A FK relationship may make on-line
archiving a parent-child table pair slower or more complicated than
if the FK relationship was managed by the app system.

Next, performance. If the server is burdened, or some of the RDBMS'
operations are inefficient, then doing the work inside the
application may be faster.

Lastly, there's politics. If the DBA/Operations team is in one
division, and the Development group is in another, the dev team
might want to keep much of the system knowledge to itself, and not
share with the DBAs.

- --
Ron Johnson, Jr.
Jefferson LA USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE3vVTS9HxQb37XmcRAl3gAJ9ZxtE5zrhkgsXBgZ8J7Y qdaIxPEgCfZ9qy
PBjxVm39dtz9crJkLrFti68=
=nKDU
-----END PGP SIGNATURE-----

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On 13/8/06 09:57, "Thomas Kellerer" <spam_eater@gmx.net> wrote:

> Harald Armin Massa wrote on 13.08.2006 10:46:
>> Do you know for what benefit that happens? I have seen similiar stupidity
>> with EJB, having RI within that layer. Why are people doing this? Do they
>> know something I miss, or did they just not vivist Databases 101 ?
>
> I think this happens because of the OO/UML hype. People tend to see the
> database
> as a mere storage facility and putting the logic (including RI and other
> stuff)
> in the middle tier. This should make the application more platform
> independent.

I see a similar issue in my line of work. Many of the programmers (even
those working for the larger software houses in the social housing sector)
have started out their careers as housing offices or maintenance surveyors
or whatever and have drifted into programming over the years. Their bosses
(in fact, in some cases they are the bosses) demand database neutrality so
they can run with whatever DBMS the client prefers and they simply take the
simple option and include all RI and other constraints in the client or
middle tier, partly because they don't know any better, but more these days
because they don't get the time or resources to do the job properly :-(

You can imagine the fun we sometimes have chasing down data errors!

Regards, Dave


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Aug 13, 2006, at 11:34 am, Dave Page wrote:
> I see a similar issue in my line of work. Many of the programmers
> (even
> those working for the larger software houses in the social housing
> sector)
> have started out their careers as housing offices or maintenance
> surveyors
> or whatever and have drifted into programming over the years. Their
> bosses
> (in fact, in some cases they are the bosses) demand database
> neutrality so
> they can run with whatever DBMS the client prefers and they simply
> take the
> simple option and include all RI and other constraints in the
> client or
> middle tier, partly because they don't know any better, but more
> these days
> because they don't get the time or resources to do the job
> properly :-(
>
> You can imagine the fun we sometimes have chasing down data errors!


Dave,

The attitude where I work is similar. Part of the problem is our
biggest app is like a plate of spaghetti... we have business rules
enforced everywhere from the Flash front-end (using ActionScript) to
the MSSQL back-end (Transact-SQL). It's anyone's guess what's left
in the C#. So on one hand it's easy to see why the developers would
like it all moved in one location.

Personally, I'm a data integrity fanatic - we've been bitten by
violated rules too often (my favourite is two tables used to store
two types of login, one must have even primary keys the other must
have odd ones we learnt after I naively did a bulk insert into
both tables that constraints to enforce bizarre things like this are
quite useful...). However, I can also see the advantage of collating
the business logic. We are trying to switch development to Ruby on
Rails which will help in that it enforces an MVC architecture
(whether the developers will actually use it correctly is another
issue), but then leaves you with the problem of having to duplicate
all the business rules (at least those that enforce purely integrity)
in the database, so they can be used for interactive GUI error
messages as well as integrity.

Out of this situation seems to come the following problems:

- developers don't care about database integrity because "the app
works without it"
- developers are therefore too lazy to even consider (learning the
skill of) writing database constraints
- because the code lacks any formal business rules, they are never
clearly and explicitly documented (so we know what they actually are!)

We also have the issue some of our customers are clueless business
types from the Church of Microsoft and don't understand that Postgres
is actually better AND cheaper than SQL Server. If any demand we use
SQL Server, you can double the complexity of including integrity.

I am the least educated person in my office (no degree) and I'm the
ONLY one who has any understanding of relational theory. I can't
understand how developers employed to created database-backed
applications think they can get anywhere with so little understanding
of what they are doing. Well actually, having seen lecture slides
from one of the developer's uni courses, I have a vague idea.

Any suggestions on how to correct this attitude (and consequently the
problems above) would be very welcome I have actually written a
10-page introduction to relational theory, based on the bad design
decisions in our apps. I intend to sit everyone round, nail their
feet to the ground, and not let them leave until they have at least
acknowledged every point. How well this is received - and how long
my job lasts afterwards - remains to be seen.

Ashley




---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq