On Thu, Mar 08, 2007 at 05:05:07AM +0900, Greg Lorriman wrote:
> By interaction I just mean recording user relationships, like when one
> user records another user as a friend on slashdot. They'll be a
> 'friend' table with two foriegn keys.
> 
> In my naive idea of things each machine would be equivalent to the
> others. They would each have Webserver->Rails->Database. Interactions
> between users means recording a new relationship between two users,
> normally quite straightforward on a single database, but requiring
> inter-machine communication and a certain amount of fiddling about
> where the user accounts are on different machines/database-backends.

And very hard (if not impossible) to enforce referential integrity on, since
user A would need to have a 'foreign key' entry pointing to user X in a
different table on a different machine.

You could solve this by each machine having at least a complete table of all
users on the system (which could be a read-only copy of a single master
table, if addition of new users is relatively infrequent compared to reading
data about users). But if you're going to do that, I'd argue you might as
well replicate *all* the data.

Also: imagine trying to make use of this 'federated' data. Say user A (on
machine 1) has a relationship with user H (on machine 2), and user H has a
relationship with user X (on machine 3). These are three tables in three
separate databases. Now try doing a join across these to find out who is
related two hops away. Ouch. This will become a very expensive operation,
requiring a series of separate queries against each of the databases. If you
had a single, central database, properly indexed, it would be a relatively
cheap single query.

Hence I think the federated approach may turn out to be a false economy
anyway.

Regards,

Brian.