List:MySQL++« Previous MessageNext Message »
From:William Pettersson Date:July 9 2008 9:34pm
Subject:Re: Duplicating tables - mysqldump or mysqlpp or?
View as plain text  
> Date: Wed, 9 Jul 2008 08:48:30 -0600 To: plusplus@stripped 
> From: Warren Young <mysqlpp@stripped> Subject: Re: Duplicating 
> tables - mysqldump or mysqlpp or? Message-Id: 
> <416A163F-DF23-4904-88BE-3F314BF7F0E6@stripped> On Jul 9, 2008, at 
> 4:39 AM, William Pettersson wrote:
>> > The eeepc needs to query a serial device (RFID reader), check some  
>> > stuff in the database and show some info.  The thing is, the eeepc  
>> > won't always have a network connection.  Actually, it rarely will.   
>> > So what I need to do is synchronise two databases, remote and local,  
>> > and then just have my app query the local database.
> This sounds like a human time scale task.  That is, records will  
> accumulate only as fast as a single person can bring them in.  Even if  
> it takes days between syncs, I can't imagine there will be all that  
> many records; hundreds, at most?  Therefore, I don't see why you're  
> worried about sync time.  Even the slow method of "read one from local  
> DB, write one to remote DB" should take a few seconds at most, even  
> over the Eee's wifi connection.
> The mysqldump method won't be trivial.  The first statement in a dump  
> file is a "DROP TABLE x IF EXISTS" followed by a "CREATE TABLE".   
> You'll have to strip that off for a sync operation.
> Also, the mysqldump method probably breaks down completely if you ever  
> have two remote users, or equivalently, if the centralized DB is  
> allowed to change while the remote user is roaming about.  You no  
> doubt have some unique ID columns, which your sync operation will have  
> to ensure remain unique in the merged DB.  You need individual records  
> insertions wrapped in error-handling logic to make this robust.
> History tells us that synchronization is hard.  Whole companies have  
> crashed and burned by doing this badly.  I wouldn't try to hack such a  
> project.  It calls for a real language.
Sorry Warren, but I forgot to mention something here.  The remote client 
is not "adding" anything to either DB, remote or local, so synchronising 
is probably the wrong word to use.  In actual fact, the "drop table then 
create table" idea will actually work just fine, and the one table that 
we need to "copy" only has about 800 rows so it shouldn't take too long 
either way.

So for a final solution, I will just implement a mysqldump call.   
Seeing as all I essentially need is a local copy of a remote table, I 
can just use mysqldump.

William Pettersson

NLT Australia
07 5495 2944

Duplicating tables - mysqldump or mysqlpp or?William Pettersson9 Jul
  • Re: Duplicating tables - mysqldump or mysqlpp or?Warren Young9 Jul
  • Re: Duplicating tables - mysqldump or mysqlpp or?Jonathan Wakely9 Jul
  • RE: Duplicating tables - mysqldump or mysqlpp or?Paul Martin9 Jul
Re: Duplicating tables - mysqldump or mysqlpp or?William Pettersson9 Jul