[ciapug] Best Practice

Claus ciapug@cialug.org
Mon, 24 Jan 2005 10:06:09 -0600


On 1/22/2005 9:47 AM, Dave J. Hala Jr. wrote:
> Ok... So...I've got this client intake system. Its written in PHP and it
> uses a mysql back end.  The information that is stored is demographic
> data on individuals and households.
> 
> I have 9 agencies that use it. Each runs agency has their own website
> and database. (they are all identical)  What I would like to do is mine
> data across all 9 agencies.  At the moment, its kinda a pain to connect,
> and query each individual database and then combine all the information.
> 
> For political reasons, I can't have all the agencies use one database.
> What I was considering is having a single "Master Database" that any
> inserts or updates done any of the 9 individuals db's would be written
> to. For example site1 does an update on the site1 db and then it does an
> update on the master db.
> 
> This method is kinda like the mysql replication. I was initially looking
> for a way to replicate all the info from one db into the master but no
> luck.  I was thinking about trying to get the query info from the mysql
> *.bin files and using it to fill the a  "master db" ( not to be confused
> with the replication master)
> 
> 
> Anyone have any thoughts? Ideas?
> 
> 
> :) Dave
> 

I'd probably consider doing an unload of new data every night (or once a 
week/month depending on your situation) and load it into the 
master/mining db.  You should be able to schedule it via cron or 
something.  This reduces the load a bit from the actual transaction and 
often mining data does not have to be up to the minute anyway.

Another alternative if you use some kind of pre-determined mining 
queries that access each database individually and pull it together. 
For example you create a web page with php that displays the mining 
data.  In that php script you might be able to pull the data from the 
various sources.

   Claus