Re[6]: [PHP-DB] database synchronization
| From: | Martin Hudec | Date: | Tue, 29 Oct 2002 10:07:01 +0000 |
| Subject: | Re[6]: [PHP-DB] database synchronization | ||
| References: | 1 | Groups: | php.db |
| Request: | Send a blank email to php-db+get-22777@lists.php.net to get a copy of this message | ||
Hello,
see below...
--
Best regards,
Martin mailto:corwin@corwin.sk
Tuesday, October 29, 2002, 10:51:17 AM, you wrote:
PL> Hi
PL> If the records are all independant - ie travel agent (TA) A has their own
PL> records and so does TA B then REPLACE INTO MainDB SELECT * FROM
PL> Travel_agent_A_DB so the main database is just receiveing updated records
PL> from the TAs.
Yes they are independent....each record has column named originTA
where i will put ID of TA which is originator of record....
PL> Travel agent logs in to master php driven site .
PL> master php driven site logs TA IP
PL> master php driven site makes connection to TA mysql using IP
Looks like i will have to write script which will monitor connection
to MySQL port on master php driven site...
PL> master php driven site gets new/updated records
PL> master php driven site writes new/updated records to master DB
okay understand ;)
PL> If more than one travel agent can update the same record then you risk
PL> corrupting the data. If they do not have a live connection to the master
PL> then the record they update may itself be out of date. The only way I can
PL> see of doing this is soem system that locks a record for the period that TA
PL> might take updating it.
so on MainDB (our slave server :)....i will create database for each partner
with designated unique name for ex. Travel_agent_A_DB...here will i
put all updated info......or I will put it to mainDB....that risk of
corruption is out of talk, because each record will have its id of
origin (Travel_agent_A_DB).....at least I hope...:) and each travel
agent will update only their records....(...WHERE
idorigin="Travel_agent_A")...
I think with this i can forget about that risk....they are updating
only their records....not anyone else's...in example....
Travel_agent_A offers Greece in 10 days from 19.6.2003 to
29.6.2003...same destination
Travel_agent_B offers Greece in 10 days from 19.6.2003 to
29.6.2003...same destination
Travel_agent_A sells out all he can in to this days...but agent_B
still has few places ;))....
update will work as follows....agent_A will update his set of
records...setting them all sold out....agent_B will update his set of
records setting ten places left to be sold....
PL> Perhaps
PL> TA A login
PL> TA grab record, mark as locked
PL> TA B gets 'locked record' message
PL> TA A updates record and writes back to master
PL> record marked as not locked
Looks good...if my upper solution will not work i will try to use
this...