Transferring Data 'Tween Databases

Sysbotz writes "A common request our company gets is how to get data from Access, Paradox, or some other database format and transfer it to a MySQL database. Well we have written a article on how to do this. W accomplish this task by writing a PHP script to read a database file through ODBC and then to construct a SQL file of the data that can then be read into MySQL. I think some slashdotters would like this."

Comments

Is this really worthy of a /. article?

[herrlich_98]

Summary: to get data from a db to MySQL use PHP to read the db and print out a MySQL script that loads all the data.

It is nice to highlight that you can read lots of different databases using odbc in PHP, but still.

This basic concept is obvious to anyone with familiarity with MySQL. I mean, come on, "pick a language that can read the database in question and use it to dump the data into a format that can be read my MySQL".

This program could have been written in Visual Basic or C# or anything that can read the database you want to convert.

A more interesting PHP program that could have taken *any* two arbitrary odbc databases (MySQL can be accessed through odbc) and dumped table definitions and data from one db to the other.

Perl DBI?

[merlyn]

The Perl DBI can talk to all of those listed databases and more. It'd be trivial to fetch everything from one database and store it in another, without worrying about local quoting conventions, as long as you use the DBI placeholders.

Re:Standarization.

[samael]

You mean some kind of Open DataBase Connectivity?

Or does ODBC not ring any bells?

As simple minded as the mods letting it pass

[Sembiance]

This is totally worthless.
Do mods just let anything with the words 'PHP' and/or 'MySQL' make it on the website?

The article is less than 2 screen pages long, it's not much more than a code dump, and it's totally hardcoded for a specific and individual database table.

It also only covers Windows installations of PHP and and person who knows that they need to move from one database to another, and what PHP is, is smart enough to do what this author wrote.

I don't diss the author on this, it looks as if he is just new to computers and doesn't know any better.
But geez, if this is the crap that we allow on slashdot now, I'm just gonna start submitting articles on 'How cool Google is'

Octopus

[grugruto]

The Enhydra Octopus project seems to be the right tool to do this and you can specify data transformations in an XML file.

You should check it out, it's open source.

More Evidence that MySQL is a toy

[bwt]

Here's another example from real world use that shows that MySQL is a toy compared to a real database like Oracle. You shouldn't have to write that much code to freaking load data. For industrial strength uses the method given will be horribly slow because it doesn't use bind variables. This results in each INSERT statement being different and having to be parsed separately by the RDBMS. SLOW!

Frankly, even the overhead of having to construct the INSERT sql string is waste. You also don't want to maintain the indexes in the target table for each row update. MySQL doesn't have transactions, so you don't have to worry about commit-frequency, but if your load stops in the middle somewhere, I'm not sure what you do.

Oracle provides a loader utility called sql*loader that eliminates the overhead of the per-row maintenance. It has a mode called "Direct Load" which can bypass trigger processing and directly write binary datablock output. This is the fastest way to load data. Of course bypassing triggers is of no interest to MySQL users because MySQL doesn't have triggers, but if it did you'd have another thing to worry about with loading data into MySQL.

As an alternate to sql*loader, you could use external tables or Oracle Generic Connectivity to create an oracle table whose data was supplied by a flat file or ODBC connection. Then you would type

INSERT INTO target_table
VALUES ( [[field_list]] )
(SELECT [[field_list]] from external_table)

or (faster)

CREATE TABLE target_table AS (SELECT * from external_table)

Both of which would blow away the proposed method speed-wise.