I'm currently trying to figure out a solution for the following situation:
A small event-management company will expand to a site in another town.
The existing office runs a homemade MS-Access DB application that I want to migrate to a more viable database server like MySQL.
The two sites will manage different projects on a partly shared customer
base. Some customers will be interested in both projects but mainly the
sites will have regional clients.
Billing should be managed by the main site.
Site 2 will collect new customers and update existing records.
Additionally they'll acquiry orders, have phone contacts, letters and
all that.
All that should be merged in the main DB dayly or weekly so that it's
known what's going on.
On the other hand new or updated customer records should be transfered
to the new site if the data appears interesting for them. E.g. site1
updates a adress of a customer who is known to take part in site2's project.
So it's not needed to keep the DBs 100% identical but every info
gathered by the new site should go to the main site.
How should I construct the db design to locate updates that have to be
transferred ?
How could I handle concurrent updates on the same record if I dont
maintain an update-timestamp on every datafield ?
For now I suspect that such update conflics will appear very rare
because they only relate to the limited set of shared customers.
Thanks
Andreas
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
