[development] Best place to store user data

[Larry Garfield]

On Monday 16 March 2009 6:44:14 pm Steve Yelvington wrote:
> Awhile back I wrote a simple module to fetch my Facebook status line,
> using an open RSS feed, and make a block to display on my blog. The
> fetched data is stored in cache for a limited period.
> http://drupal.org/project/fbstatus
>
> I've received a number of requests to upgrade the module to support
> multi-user scenarios. In such a case, cache obviously isn't the right
> place to put the data.

Why obviously?  Cache is for non-persistent data that is expensive to generate 
or retrieve but that you want to have fast access to.  Locally caching 
facebook data seems perfectly reasonable for that.

> But since there should be no more than  one Facebook account per user,
> it seemed that creating a table (as seen in the Twitter module) would be
> overkill.

Why?  There are tons of modules that add one table per user or per node in 
order to extend those entities.  That's the way modules are supposed to work.  
It's why hook_nodeapi op load and hook_user op load exist.  

> So I began looking at using profile fields (requiring profile.module) or
> the serialized user data.

Do not use $user->data.  It's only kept around as a booby trap to break the 
brains of unsuspecting new developers with strange and obscure bugs they do 
not understand.  

Profile.module is not much better, and is hopefully slated for execution in 
Drupal 7.

> But I'm likely to move the updates into hook_cron, and I can imagine a
> large site having to step through the whole user base, looking for
> statuses needing updates.
>
> So now I'm back at a discrete table.
>
> Is my thinking right?

Nothing wrong with a discrete table or the cache in this case.  The main 
question is whether you want to lazy-fetch data on users (and therefore have 
an easy "rebuild all" command; just empty the appropriate cache table) and 
then not be able to query directly against the local data, or want to have to 
maintain your own data tables and handle synchronization of data but have 
persistent, easily-queried-against local tables you could even expose to 
Views.  (Oooo...)

Either way works.  Off the cuff I'd probably go for the discrete table myself, 
but there are good arguments either way.

-- 
Larry Garfield
larry at garfieldtech.com